Vulnerability-Lookup

CVE-2024-36954 (GCVE-0-2024-36954)

Vulnerability from cvelistv5 – Published: 2024-05-30 15:35 – Updated: 2026-05-23 15:47

Title

tipc: fix a possible memleak in tipc_buf_append

Summary

In the Linux kernel, the following vulnerability has been resolved: tipc: fix a possible memleak in tipc_buf_append __skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path.

Severity

No CVSS data available.

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2024-09-10 17:15 UTC

Assigner

Linux mitre root

References

10 references

URL	Tags
https://git.kernel.org/stable/c/01cd1b7b685751ee4…
https://git.kernel.org/stable/c/2f87fd9476cf9725d…
https://git.kernel.org/stable/c/adbce6d20da6254c8…
https://git.kernel.org/stable/c/42c8471b0566c7539…
https://git.kernel.org/stable/c/d03a82f4f8144befd…
https://git.kernel.org/stable/c/614c5a5ae45a92159…
https://git.kernel.org/stable/c/3210d34fda4caff21…
https://git.kernel.org/stable/c/97bf6f81b29a8efaf…
https://lists.debian.org/debian-lts-announce/2024…	x_transferred
https://lists.debian.org/debian-lts-announce/2024…	x_transferred

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 4b1761898861117c97066aea6c58f68a7787f0bf , < 01cd1b7b685751ee422d00d050292a3d277652d6 (git) Affected: 64d17ec9f1ded042c4b188d15734f33486ed9966 , < 2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae (git) Affected: 6da24cfc83ba4f97ea44fc7ae9999a006101755c , < adbce6d20da6254c86425a8d4359b221b5ccbccd (git) Affected: b7df21cf1b79ab7026f545e7bf837bd5750ac026 , < 42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c (git) Affected: b7df21cf1b79ab7026f545e7bf837bd5750ac026 , < d03a82f4f8144befdc10518e732e2a60b34c870e (git) Affected: b7df21cf1b79ab7026f545e7bf837bd5750ac026 , < 614c5a5ae45a921595952117b2e2bd4d4bf9b574 (git) Affected: b7df21cf1b79ab7026f545e7bf837bd5750ac026 , < 3210d34fda4caff212cb53729e6bd46de604d565 (git) Affected: b7df21cf1b79ab7026f545e7bf837bd5750ac026 , < 97bf6f81b29a8efaf5d0983251a7450e5794370d (git) Affected: b2c8d28c34b3070407cb1741f9ba3f15d0284b8b (git) Affected: 5489f30bb78ff0dafb4229a69632afc2ba20765c (git) Affected: 436d650d374329a591c30339a91fa5078052ed1e (git) Affected: ace300eecbccaa698e2b472843c74a5f33f7dce8 (git) Affected: 4.19.193 , < 4.19.314 (semver) Affected: 5.4.124 , < 5.4.276 (semver) Affected: 5.10.42 , < 5.10.217 (semver) Affected: 4.4.271 , < 4.5 (semver) Affected: 4.9.271 , < 4.10 (semver) Affected: 4.14.235 , < 4.15 (semver) Affected: 5.12.9 , < 5.13 (semver)	guessed
Linux	Linux	Affected: 5.13 Unaffected: 0 , < 5.13 (semver) Unaffected: 4.19.314 , ≤ 4.19.* (semver) Unaffected: 5.4.276 , ≤ 5.4.* (semver) Unaffected: 5.10.217 , ≤ 5.10.* (semver) Unaffected: 5.15.159 , ≤ 5.15.* (semver) Unaffected: 6.1.91 , ≤ 6.1.* (semver) Unaffected: 6.6.31 , ≤ 6.6.* (semver) Unaffected: 6.8.10 , ≤ 6.8.* (semver) Unaffected: 6.9 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T03:43:50.499Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-36954",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T17:15:38.594682Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-11T17:34:59.306Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/tipc/msg.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "01cd1b7b685751ee422d00d050292a3d277652d6",
              "status": "affected",
              "version": "4b1761898861117c97066aea6c58f68a7787f0bf",
              "versionType": "git"
            },
            {
              "lessThan": "2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae",
              "status": "affected",
              "version": "64d17ec9f1ded042c4b188d15734f33486ed9966",
              "versionType": "git"
            },
            {
              "lessThan": "adbce6d20da6254c86425a8d4359b221b5ccbccd",
              "status": "affected",
              "version": "6da24cfc83ba4f97ea44fc7ae9999a006101755c",
              "versionType": "git"
            },
            {
              "lessThan": "42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c",
              "status": "affected",
              "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
              "versionType": "git"
            },
            {
              "lessThan": "d03a82f4f8144befdc10518e732e2a60b34c870e",
              "status": "affected",
              "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
              "versionType": "git"
            },
            {
              "lessThan": "614c5a5ae45a921595952117b2e2bd4d4bf9b574",
              "status": "affected",
              "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
              "versionType": "git"
            },
            {
              "lessThan": "3210d34fda4caff212cb53729e6bd46de604d565",
              "status": "affected",
              "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
              "versionType": "git"
            },
            {
              "lessThan": "97bf6f81b29a8efaf5d0983251a7450e5794370d",
              "status": "affected",
              "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "b2c8d28c34b3070407cb1741f9ba3f15d0284b8b",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "5489f30bb78ff0dafb4229a69632afc2ba20765c",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "436d650d374329a591c30339a91fa5078052ed1e",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "ace300eecbccaa698e2b472843c74a5f33f7dce8",
              "versionType": "git"
            },
            {
              "lessThan": "4.19.314",
              "status": "affected",
              "version": "4.19.193",
              "versionType": "semver"
            },
            {
              "lessThan": "5.4.276",
              "status": "affected",
              "version": "5.4.124",
              "versionType": "semver"
            },
            {
              "lessThan": "5.10.217",
              "status": "affected",
              "version": "5.10.42",
              "versionType": "semver"
            },
            {
              "lessThan": "4.5",
              "status": "affected",
              "version": "4.4.271",
              "versionType": "semver"
            },
            {
              "lessThan": "4.10",
              "status": "affected",
              "version": "4.9.271",
              "versionType": "semver"
            },
            {
              "lessThan": "4.15",
              "status": "affected",
              "version": "4.14.235",
              "versionType": "semver"
            },
            {
              "lessThan": "5.13",
              "status": "affected",
              "version": "5.12.9",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/tipc/msg.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.13"
            },
            {
              "lessThan": "5.13",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.314",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.276",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.217",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.159",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.91",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.31",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.9",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.19.314",
                  "versionStartIncluding": "4.19.193",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.276",
                  "versionStartIncluding": "5.4.124",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.217",
                  "versionStartIncluding": "5.10.42",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.159",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.91",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.31",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.8.10",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.9",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "4.4.271",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "4.9.271",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "4.14.235",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "5.12.9",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix a possible memleak in tipc_buf_append\n\n__skb_linearize() doesn\u0027t free the skb when it fails, so move\n\u0027*buf = NULL\u0027 after __skb_linearize(), so that the skb can be\nfreed on the err path."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-23T15:47:43.810Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6"
        },
        {
          "url": "https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae"
        },
        {
          "url": "https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd"
        },
        {
          "url": "https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c"
        },
        {
          "url": "https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e"
        },
        {
          "url": "https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574"
        },
        {
          "url": "https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565"
        },
        {
          "url": "https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d"
        }
      ],
      "title": "tipc: fix a possible memleak in tipc_buf_append",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-36954",
    "datePublished": "2024-05-30T15:35:48.665Z",
    "dateReserved": "2024-05-30T15:25:07.080Z",
    "dateUpdated": "2026-05-23T15:47:43.810Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-36954",
      "date": "2026-09-22",
      "epss": "0.00249",
      "percentile": "0.16603"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "net/tipc/msg.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "01cd1b7b685751ee422d00d050292a3d277652d6",
                    "status": "affected",
                    "version": "4b1761898861117c97066aea6c58f68a7787f0bf",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae",
                    "status": "affected",
                    "version": "64d17ec9f1ded042c4b188d15734f33486ed9966",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "adbce6d20da6254c86425a8d4359b221b5ccbccd",
                    "status": "affected",
                    "version": "6da24cfc83ba4f97ea44fc7ae9999a006101755c",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c",
                    "status": "affected",
                    "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "d03a82f4f8144befdc10518e732e2a60b34c870e",
                    "status": "affected",
                    "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "614c5a5ae45a921595952117b2e2bd4d4bf9b574",
                    "status": "affected",
                    "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "3210d34fda4caff212cb53729e6bd46de604d565",
                    "status": "affected",
                    "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "97bf6f81b29a8efaf5d0983251a7450e5794370d",
                    "status": "affected",
                    "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                    "versionType": "git"
                  },
                  {
                    "status": "affected",
                    "version": "b2c8d28c34b3070407cb1741f9ba3f15d0284b8b",
                    "versionType": "git"
                  },
                  {
                    "status": "affected",
                    "version": "5489f30bb78ff0dafb4229a69632afc2ba20765c",
                    "versionType": "git"
                  },
                  {
                    "status": "affected",
                    "version": "436d650d374329a591c30339a91fa5078052ed1e",
                    "versionType": "git"
                  },
                  {
                    "status": "affected",
                    "version": "ace300eecbccaa698e2b472843c74a5f33f7dce8",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "4.19.314",
                    "status": "affected",
                    "version": "4.19.193",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "5.4.276",
                    "status": "affected",
                    "version": "5.4.124",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "5.10.217",
                    "status": "affected",
                    "version": "5.10.42",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.5",
                    "status": "affected",
                    "version": "4.4.271",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.10",
                    "status": "affected",
                    "version": "4.9.271",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "4.15",
                    "status": "affected",
                    "version": "4.14.235",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "5.13",
                    "status": "affected",
                    "version": "5.12.9",
                    "versionType": "semver"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "net/tipc/msg.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "5.13"
                  },
                  {
                    "lessThan": "5.13",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "4.19.*",
                    "status": "unaffected",
                    "version": "4.19.314",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.4.*",
                    "status": "unaffected",
                    "version": "5.4.276",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.217",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.159",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.91",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.31",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.8.*",
                    "status": "unaffected",
                    "version": "6.8.10",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "6.9",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "E1B511FF-B35C-4F12-BC59-FC0C59B5ED9B",
                    "versionEndExcluding": "4.5",
                    "versionStartIncluding": "4.4.271",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "7F201161-7061-4D21-AB64-08FE904827C3",
                    "versionEndExcluding": "4.10",
                    "versionStartIncluding": "4.9.271",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "5B377D18-E1AC-4086-BD80-E5A6E29501C2",
                    "versionEndExcluding": "4.15",
                    "versionStartIncluding": "4.14.235",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "CC3FE8F6-AF63-41C0-BCD1-8A6DF9BB8B9E",
                    "versionEndExcluding": "4.19.314",
                    "versionStartIncluding": "4.19.193",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "0C2251C5-3675-475C-A6CF-65DCB7DF9763",
                    "versionEndExcluding": "5.4.276",
                    "versionStartIncluding": "5.4.124",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "A43FC5E3-31B4-40D2-A5F9-DCE255ACC316",
                    "versionEndExcluding": "5.10.217",
                    "versionStartIncluding": "5.10.42",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "73FC57AB-D423-4492-B328-1585612B34E6",
                    "versionEndExcluding": "5.15.159",
                    "versionStartIncluding": "5.12.9",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "4F8C886C-75AA-469B-A6A9-12BF1A29C0D5",
                    "versionEndExcluding": "6.1.91",
                    "versionStartIncluding": "5.16",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "CDDB1F69-36AC-41C1-9192-E7CCEF5FFC00",
                    "versionEndExcluding": "6.6.31",
                    "versionStartIncluding": "6.2",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "6A6B920C-8D8F-4130-86B4-AD334F4CF2E3",
                    "versionEndExcluding": "6.8.10",
                    "versionStartIncluding": "6.7",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc1:*:*:*:*:*:*",
                    "matchCriteriaId": "22BEDD49-2C6D-402D-9DBF-6646F6ECD10B",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc2:*:*:*:*:*:*",
                    "matchCriteriaId": "DF73CB2A-DFFD-46FB-9BFE-AA394F27EA37",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc3:*:*:*:*:*:*",
                    "matchCriteriaId": "52048DDA-FC5A-4363-95A0-A6357B4D7F8C",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc4:*:*:*:*:*:*",
                    "matchCriteriaId": "A06B2CCF-3F43-4FA9-8773-C83C3F5764B2",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc5:*:*:*:*:*:*",
                    "matchCriteriaId": "F850DCEC-E08B-4317-A33B-D2DCF39F601B",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc6:*:*:*:*:*:*",
                    "matchCriteriaId": "91326417-E981-482E-A5A3-28BC1327521B",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          },
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
                    "matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix a possible memleak in tipc_buf_append\n\n__skb_linearize() doesn\u0027t free the skb when it fails, so move\n\u0027*buf = NULL\u0027 after __skb_linearize(), so that the skb can be\nfreed on the err path."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: soluciona un posible memleak en tipc_buf_append __skb_linearize() no libera el skb cuando falla, as\u00ed que mueve \u0027*buf = NULL\u0027 despu\u00e9s de __skb_linearize(), para que el skb se puede liberar en la ruta de error."
          }
        ],
        "id": "CVE-2024-36954",
        "lastModified": "2026-06-17T07:37:26.603",
        "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-2024-36954",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T17:15:38.594682Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-05-30T16:15:18.313",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Mailing List"
            ],
            "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Mailing List"
            ],
            "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-401"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2026-06-28T07:06:24+00:00",
      "cve": "CVE-2024-36954",
      "id": "CVE-2024-36954",
      "initial_release_date": "2024-05-30T00:00:00+00:00",
      "product_status:fixed": "429",
      "product_status:known_affected": "108",
      "product_status:known_not_affected": "42",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: tipc: fix a possible memleak in tipc_buf_append",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-36954.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "providerMetadata": {
              "dateUpdated": "2024-08-02T03:43:50.499Z",
              "orgId": "af854a3a-2127-422b-91ae-364da2661108",
              "shortName": "CVE"
            },
            "references": [
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
              }
            ],
            "title": "CVE Program Container"
          },
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2024-36954",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-09-10T17:15:38.594682Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-09-11T12:42:27.333Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "net/tipc/msg.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "01cd1b7b685751ee422d00d050292a3d277652d6",
                  "status": "affected",
                  "version": "4b1761898861117c97066aea6c58f68a7787f0bf",
                  "versionType": "git"
                },
                {
                  "lessThan": "2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae",
                  "status": "affected",
                  "version": "64d17ec9f1ded042c4b188d15734f33486ed9966",
                  "versionType": "git"
                },
                {
                  "lessThan": "adbce6d20da6254c86425a8d4359b221b5ccbccd",
                  "status": "affected",
                  "version": "6da24cfc83ba4f97ea44fc7ae9999a006101755c",
                  "versionType": "git"
                },
                {
                  "lessThan": "42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c",
                  "status": "affected",
                  "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                  "versionType": "git"
                },
                {
                  "lessThan": "d03a82f4f8144befdc10518e732e2a60b34c870e",
                  "status": "affected",
                  "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                  "versionType": "git"
                },
                {
                  "lessThan": "614c5a5ae45a921595952117b2e2bd4d4bf9b574",
                  "status": "affected",
                  "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                  "versionType": "git"
                },
                {
                  "lessThan": "3210d34fda4caff212cb53729e6bd46de604d565",
                  "status": "affected",
                  "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                  "versionType": "git"
                },
                {
                  "lessThan": "97bf6f81b29a8efaf5d0983251a7450e5794370d",
                  "status": "affected",
                  "version": "b7df21cf1b79ab7026f545e7bf837bd5750ac026",
                  "versionType": "git"
                },
                {
                  "status": "affected",
                  "version": "b2c8d28c34b3070407cb1741f9ba3f15d0284b8b",
                  "versionType": "git"
                },
                {
                  "status": "affected",
                  "version": "5489f30bb78ff0dafb4229a69632afc2ba20765c",
                  "versionType": "git"
                },
                {
                  "status": "affected",
                  "version": "436d650d374329a591c30339a91fa5078052ed1e",
                  "versionType": "git"
                },
                {
                  "status": "affected",
                  "version": "ace300eecbccaa698e2b472843c74a5f33f7dce8",
                  "versionType": "git"
                },
                {
                  "lessThan": "4.19.314",
                  "status": "affected",
                  "version": "4.19.193",
                  "versionType": "semver"
                },
                {
                  "lessThan": "5.4.276",
                  "status": "affected",
                  "version": "5.4.124",
                  "versionType": "semver"
                },
                {
                  "lessThan": "5.10.217",
                  "status": "affected",
                  "version": "5.10.42",
                  "versionType": "semver"
                },
                {
                  "lessThan": "4.5",
                  "status": "affected",
                  "version": "4.4.271",
                  "versionType": "semver"
                },
                {
                  "lessThan": "4.10",
                  "status": "affected",
                  "version": "4.9.271",
                  "versionType": "semver"
                },
                {
                  "lessThan": "4.15",
                  "status": "affected",
                  "version": "4.14.235",
                  "versionType": "semver"
                },
                {
                  "lessThan": "5.13",
                  "status": "affected",
                  "version": "5.12.9",
                  "versionType": "semver"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "net/tipc/msg.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "5.13"
                },
                {
                  "lessThan": "5.13",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "4.19.*",
                  "status": "unaffected",
                  "version": "4.19.314",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.4.*",
                  "status": "unaffected",
                  "version": "5.4.276",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.10.*",
                  "status": "unaffected",
                  "version": "5.10.217",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.15.*",
                  "status": "unaffected",
                  "version": "5.15.159",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.1.*",
                  "status": "unaffected",
                  "version": "6.1.91",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.31",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.8.*",
                  "status": "unaffected",
                  "version": "6.8.10",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "6.9",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "cpeApplicability": [
            {
              "nodes": [
                {
                  "cpeMatch": [
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "4.19.314",
                      "versionStartIncluding": "4.19.193",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.4.276",
                      "versionStartIncluding": "5.4.124",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.10.217",
                      "versionStartIncluding": "5.10.42",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.15.159",
                      "versionStartIncluding": "5.13",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.1.91",
                      "versionStartIncluding": "5.13",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.6.31",
                      "versionStartIncluding": "5.13",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.8.10",
                      "versionStartIncluding": "5.13",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.9",
                      "versionStartIncluding": "5.13",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionStartIncluding": "4.4.271",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionStartIncluding": "4.9.271",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionStartIncluding": "4.14.235",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionStartIncluding": "5.12.9",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix a possible memleak in tipc_buf_append\n\n__skb_linearize() doesn\u0027t free the skb when it fails, so move\n\u0027*buf = NULL\u0027 after __skb_linearize(), so that the skb can be\nfreed on the err path."
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-05-23T15:47:43.810Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6"
            },
            {
              "url": "https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae"
            },
            {
              "url": "https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd"
            },
            {
              "url": "https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c"
            },
            {
              "url": "https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e"
            },
            {
              "url": "https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574"
            },
            {
              "url": "https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565"
            },
            {
              "url": "https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d"
            }
          ],
          "title": "tipc: fix a possible memleak in tipc_buf_append",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2024-36954",
        "datePublished": "2024-05-30T15:35:48.665Z",
        "dateReserved": "2024-05-30T15:25:07.080Z",
        "dateUpdated": "2026-05-23T15:47:43.810Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

OESA-2024-1737 (CVE-2021-47366)

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

afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server

AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value.

This is a problem, however, since the file position and length fields of FS.FetchData are signed 32-bit values.

Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to switch on the parameter values.

This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that.

Note that the issue does not exist with FS.StoreData - that uses unsigned 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values.

This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client1. Provided the clone has a pack file that's in the 2G-4G range, the git status will show errors like:

error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index

This can be observed in the server's FileLog with something like the following appearing:

Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5

Note the file position of 18446744071815340032. This is the requested file position sign-extended.(CVE-2021-47366)

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

net/smc: Fix possible access to freed memory in link clear

After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context.

Here is a crash example:

BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> _raw_spin_lock_irqsave+0x30/0x40 mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib] smc_wr_rx_tasklet_fn+0x56/0xa0 [smc] tasklet_action_common.isra.21+0x66/0x100 __do_softirq+0xd5/0x29c asm_call_irq_on_stack+0x12/0x20 </IRQ> do_softirq_own_stack+0x37/0x40 irq_exit_rcu+0x9d/0xa0 sysvec_call_function_single+0x34/0x80 asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)

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

soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs

In brcmstb_pm_probe(), there are two kinds of leak bugs:

(1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)

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:

pipe: wakeup wr_wait after setting max_usage

Commit c73be61cede5 ("pipe: Add general notification queue support") a regression was introduced that would lock up resized pipes under certain conditions. See the reproducer in 1.

The commit resizing the pipe ring size was moved to a different function, doing that moved the wakeup for pipe->wr_wait before actually raising pipe->max_usage. If a pipe was full before the resize occured it would result in the wakeup never actually triggering pipe_write.

Set @max_usage and @nr_accounted before waking writers if this isn't a watch queue.

Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues

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

ACPI: video: check for error while searching for backlight device parent

If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device.

Check acpi_get_parent() result and set parent device only in case of success.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)

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

mmc: mmc_spi: fix error handling in mmc_spi_probe()

If mmc_add_host() fails, it doesn't need to call mmc_remove_host(), or it will cause null-ptr-deref, because of deleting a not added device in mmc_remove_host().

To fix this, goto label 'fail_glue_init', if mmc_add_host() fails, and change the label 'fail_add_host' to 'fail_gpiod_request'.(CVE-2023-52708)

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

ceph: blocklist the kclient when receiving corrupted snap trace

When received corrupted snap trace we don't know what exactly has happened in MDS side. And we shouldn't continue IOs and metadatas access to MDS, which may corrupt or get incorrect contents.

This patch will just block all the further IO/MDS requests immediately and then evict the kclient itself.

The reason why we still need to evict the kclient just after blocking all the further IOs is that the MDS could revoke the caps faster.(CVE-2023-52732)

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:

IB/hfi1: Restore allocated resources on failed copyout

Fix a resource leak if an error occurs.(CVE-2023-52747)

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

virtio-blk: fix implicit overflow on virtio_max_dma_size

The following codes have an implicit conversion from size_t to u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev);

This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead.(CVE-2023-52762)

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

fs/jfs: Add check for negative db_l2nbperpage

l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative.

In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent.

Syzbot reported this bug:

UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative(CVE-2023-52810)

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

drm/panel: fix a possible null pointer dereference

In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)

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

media: vidtv: mux: Add check and kfree for kstrdup

Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak.(CVE-2023-52841)

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

hsr: Prevent use after free in prp_create_tagged_frame()

The prp_fill_rct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value.(CVE-2023-52846)

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

clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change

While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.(CVE-2023-52882)

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

ksmbd: validate request buffer size in smb2_allocate_rsp_buf()

The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)

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

ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses

Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel1, the system crashed during some uio test with the following memory layout:

node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is：0xc0900000, 0x100000

the crash backtrace like:

Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception

So check if PG_reserved was set to solve this issue.

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

ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()

If ->NameOffset of smb2_create_req is smaller than Buffer offset of smb2_create_req, slab-out-of-bounds read can happen from smb2_open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2_create_req().(CVE-2024-26954)

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

mm: swap: fix race between free_swap_and_cache() and swapoff()

There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.

This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).

Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().

Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):

--8<-----

__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".

swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.

So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().

Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.

Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.

Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]

Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE

Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().

__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);

What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?

--8<-----(CVE-2024-26960)

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

net/mlx5e: Prevent deadlock while disabling aRFS

When disabling aRFS under the priv->state_lock, any scheduled aRFS works are canceled using the cancel_work_sync function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the state_lock which is already acquired.

The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.

Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.

Kernel log:

====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I

ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0

but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20

-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e

other info that might help us debug this:

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work));

*** DEADLOCK ***

3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]

stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---(CVE-2024-27014)

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

netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()

nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry.

Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)

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

drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'

The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL.

Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)(CVE-2024-27044)

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

net: ll_temac: platform_get_resource replaced by wrong function

The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name.

This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp.

if (type == resource_type(r) &amp;&amp; !strcmp(r-&gt;name, name))

It should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)

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

fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion

The first kiocb_set_cancel_fn() argument may point at a struct kiocb that is not embedded inside struct aio_kiocb. With the current code, depending on the compiler, the req->ki_ctx read happens either before the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such that it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)

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

soc: fsl: qbman: Use raw spinlock for cgr_lock

smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task.

Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down.(CVE-2024-35819)

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

wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()

In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)

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

netfilter: bridge: replace physindev with physinif in nf_bridge_info

An skb can be added to a neigh->arp_queue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arp_queue of the bridge.

As skb->dev can be reset back to nf_bridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack:

arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish

Let's use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.(CVE-2024-35839)

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

smb: client: fix UAF in smb2_reconnect_server()

The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING.

To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down.

The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc:

kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-35870)

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

ax25: fix use-after-free bugs caused by ax25_ds_del_timer

When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below:

  (Thread 1)          |      (Thread 2)
                      | ax25_ds_timeout()

In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.(CVE-2024-35887)

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

tcp: properly terminate timers for kernel sockets

We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled.

Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago.

When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers.

inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later.

For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns.

For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns.

This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler.

Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held.

It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)

We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)

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

drm/vc4: don't check if plane->state->fb == state->fb

Currently, when using non-blocking commits, we can see the following kernel warning:

[ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]---

This happens because, although prepare_fb and cleanup_fb are perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount in prepare_fb and don't decrease it in cleanup_fb. The opposite can also be true.

In fact, the struct drm_plane .state shouldn't be accessed directly but instead, the drm_atomic_get_new_plane_state() helper function should be used. So, we could stick to this check, but using drm_atomic_get_new_plane_state(). But actually, this check is not re ---truncated---(CVE-2024-35932)

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

btrfs: send: handle path ref underflow in header iterate_inode_ref()

Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.(CVE-2024-35935)

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

wifi: cfg80211: check A-MSDU format more carefully

If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.(CVE-2024-35937)

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

drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()

Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()

If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called.(CVE-2024-35951)

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

Bluetooth: L2CAP: Fix not validating setsockopt user input

Check user input length before copying data.(CVE-2024-35965)

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

Bluetooth: RFCOMM: Fix not validating setsockopt user input

syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length.

BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)

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

batman-adv: Avoid infinite loop trying to resize local TT

If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet.

But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of

batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)

in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more.

There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes.

While this should be handled proactively when:

interface with too low MTU is added
VLAN is added
non-purgeable local mac is added
MTU of an attached interface is reduced
fragmentation setting gets disabled (which most likely requires dropping attached interfaces)

not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present.(CVE-2024-35982)

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

tty: n_gsm: fix possible out-of-bounds in gsm0_receive()

Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.

Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.

All other checks remain as we still need to limit the data according to the user configuration and actual payload size.(CVE-2024-36016)

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

blk-iocost: avoid out of bounds shift

UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures.

[ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020 Call Trace: <IRQ> dump_stack_lvl+0x8f/0xe0 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x1f80 __run_timer_base+0x1b6/0x250 ...

Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large.

I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug.(CVE-2024-36916)

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

block: fix overflow in blk_ioctl_discard()

There is no check for overflow of 'start + len' in blk_ioctl_discard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now.(CVE-2024-36917)

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

scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload

The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required.

This will suppress following BUG_ON():

[ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? rescuer_thread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? set_kthread_struct+0x40/0x40 [ 450.044411] ret_from_fork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)

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

s390/qeth: Fix kernel panic after setting hsuid

Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL.

Example:

[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98 [ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv] [ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv] [ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv] [ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt

Analysis: There is one napi structure per out_q: card->qdio.out_qs[i].napi The napi.poll functions are set during qeth_open().

Since commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)") qeth_set_offline()/qeth_set_online() no longer call dev_close()/ dev_open(). So if qeth_free_qdio_queues() cleared card->qdio.out_qs[i].napi.poll while the network interface was UP and the card was offline, they are not set again.

Reproduction: chzdev -e $devno layer2=0 ip link set dev $network_interface up echo 0 > /sys/bus/ccw ---truncated---(CVE-2024-36928)

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

scsi: lpfc: Move NPIV's transport unregistration to after resource clean up

There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric.

Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch.

Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.(CVE-2024-36952)

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

tipc: fix a possible memleak in tipc_buf_append

__skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path.(CVE-2024-36954)

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

drm/vmwgfx: Fix invalid reads in fence signaled events

Correctly set the length of the drm_event to the size of the structure that's actually used.

The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.(CVE-2024-36960)

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

Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()

l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range.

Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value.

divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---(CVE-2024-36968)

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)

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-47366	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48673	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48693	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52670	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52672	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52693	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52708	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52732	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52739	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52747	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52762	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52810	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52821	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52841	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52846	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52882	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26936	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26947	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26954	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26960	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27014	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27019	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27044	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35796	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35815	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35819	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35828	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35839	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35870	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35887	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35910	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35932	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35935	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35937	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35951	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35965	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35966	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35982	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36016	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36916	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36917	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36919	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36928	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36952	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36954	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36960	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36968	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36971	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-source-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "kernel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.80.0.160.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "kernel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.80.0.160.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.80.0.160.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\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\r\n\r\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\nLinux\u0026apos;s afs client switches between them when talking to a non-YFS server\nif the read size, the file position or the sum of the two have the upper 32\nbits set of the 64-bit value.\r\n\r\nThis is a problem, however, since the file position and length fields of\nFS.FetchData are *signed* 32-bit values.\r\n\r\nFix this by capturing the capability bits obtained from the fileserver when\nit\u0026apos;s sent an FS.GetCapabilities RPC, rather than just discarding them, and\nthen picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\nswitch on the parameter values.\r\n\r\nThis capabilities flag could also be used to limit the maximum size of the\nfile, but all servers must be checked for that.\r\n\r\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\n32-bit values.  It\u0026apos;s also not a problem with Auristor servers as its\nYFS.FetchData64 op uses unsigned 64-bit values.\r\n\r\nThis can be tested by cloning a git repo through an OpenAFS client to an\nOpenAFS server and then doing \u0026quot;git status\u0026quot; on it from a Linux afs\nclient[1].  Provided the clone has a pack file that\u0026apos;s in the 2G-4G range,\nthe git status will show errors like:\r\n\r\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\r\n\r\nThis can be observed in the server\u0026apos;s FileLog with something like the\nfollowing appearing:\r\n\r\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\n...\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\r\n\r\nNote the file position of 18446744071815340032.  This is the requested file\nposition sign-extended.(CVE-2021-47366)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Fix possible access to freed memory in link clear\r\n\r\nAfter modifying the QP to the Error state, all RX WR would be completed\nwith WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not\nwait for it is done, but destroy the QP and free the link group directly.\nSo there is a risk that accessing the freed memory in tasklet context.\r\n\r\nHere is a crash example:\r\n\r\n BUG: unable to handle page fault for address: ffffffff8f220860\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060\n Oops: 0002 [#1] SMP PTI\n CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE     5.10.0-0607+ #23\n Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018\n RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0\n Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e \u0026lt;48\u0026gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32\n RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086\n RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000\n RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00\n RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b\n R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010\n R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040\n FS:  0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  _raw_spin_lock_irqsave+0x30/0x40\n  mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]\n  smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]\n  tasklet_action_common.isra.21+0x66/0x100\n  __do_softirq+0xd5/0x29c\n  asm_call_irq_on_stack+0x12/0x20\n  \u0026lt;/IRQ\u0026gt;\n  do_softirq_own_stack+0x37/0x40\n  irq_exit_rcu+0x9d/0xa0\n  sysvec_call_function_single+0x34/0x80\n  asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs\r\n\r\nIn brcmstb_pm_probe(), there are two kinds of leak bugs:\r\n\r\n(1) we need to add of_node_put() when for_each__matching_node() breaks\n(2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)\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\npipe: wakeup wr_wait after setting max_usage\r\n\r\nCommit c73be61cede5 (\u0026quot;pipe: Add general notification queue support\u0026quot;) a\nregression was introduced that would lock up resized pipes under certain\nconditions. See the reproducer in [1].\r\n\r\nThe commit resizing the pipe ring size was moved to a different\nfunction, doing that moved the wakeup for pipe-\u0026gt;wr_wait before actually\nraising pipe-\u0026gt;max_usage. If a pipe was full before the resize occured it\nwould result in the wakeup never actually triggering pipe_write.\r\n\r\nSet @max_usage and @nr_accounted before waking writers if this isn\u0026apos;t a\nwatch queue.\r\n\r\n[Christian Brauner \u0026lt;brauner@kernel.org\u0026gt;: rewrite to account for watch queues](CVE-2023-52672)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: video: check for error while searching for backlight device parent\r\n\r\nIf acpi_get_parent() called in acpi_video_dev_register_backlight()\nfails, for example, because acpi_ut_acquire_mutex() fails inside\nacpi_get_parent), this can lead to incorrect (uninitialized)\nacpi_parent handle being passed to acpi_get_pci_dev() for detecting\nthe parent pci device.\r\n\r\nCheck acpi_get_parent() result and set parent device only in case of success.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_spi: fix error handling in mmc_spi_probe()\r\n\r\nIf mmc_add_host() fails, it doesn\u0026apos;t need to call mmc_remove_host(),\nor it will cause null-ptr-deref, because of deleting a not added\ndevice in mmc_remove_host().\r\n\r\nTo fix this, goto label \u0026apos;fail_glue_init\u0026apos;, if mmc_add_host() fails,\nand change the label \u0026apos;fail_add_host\u0026apos; to \u0026apos;fail_gpiod_request\u0026apos;.(CVE-2023-52708)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nceph: blocklist the kclient when receiving corrupted snap trace\r\n\r\nWhen received corrupted snap trace we don\u0026apos;t know what exactly has\nhappened in MDS side. And we shouldn\u0026apos;t continue IOs and metadatas\naccess to MDS, which may corrupt or get incorrect contents.\r\n\r\nThis patch will just block all the further IO/MDS requests\nimmediately and then evict the kclient itself.\r\n\r\nThe reason why we still need to evict the kclient just after\nblocking all the further IOs is that the MDS could revoke the caps\nfaster.(CVE-2023-52732)\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\nIB/hfi1: Restore allocated resources on failed copyout\r\n\r\nFix a resource leak if an error occurs.(CVE-2023-52747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio-blk: fix implicit overflow on virtio_max_dma_size\r\n\r\nThe following codes have an implicit conversion from size_t to u32:\n(u32)max_size = (size_t)virtio_max_dma_size(vdev);\r\n\r\nThis may lead overflow, Ex (size_t)4G -\u0026gt; (u32)0. Once\nvirtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX\ninstead.(CVE-2023-52762)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add check for negative db_l2nbperpage\r\n\r\nl2nbperpage is log2(number of blks per page), and the minimum legal\nvalue should be 0, not negative.\r\n\r\nIn the case of l2nbperpage being negative, an error will occur\nwhen subsequently used as shift exponent.\r\n\r\nSyzbot reported this bug:\r\n\r\nUBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12\nshift exponent -16777216 is negative(CVE-2023-52810)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: fix a possible null pointer dereference\r\n\r\nIn versatile_panel_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vidtv: mux: Add check and kfree for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.\nMoreover, use kfree() in the later error handling in order to avoid\nmemory leak.(CVE-2023-52841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhsr: Prevent use after free in prp_create_tagged_frame()\r\n\r\nThe prp_fill_rct() function can fail.  In that situation, it frees the\nskb and returns NULL.  Meanwhile on the success path, it returns the\noriginal skb.  So it\u0026apos;s straight forward to fix bug by using the returned\nvalue.(CVE-2023-52846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change\r\n\r\nWhile PLL CPUX clock rate change when CPU is running from it works in\nvast majority of cases, now and then it causes instability. This leads\nto system crashes and other undefined behaviour. After a lot of testing\n(30+ hours) while also doing a lot of frequency switches, we can\u0026apos;t\nobserve any instability issues anymore when doing reparenting to stable\nclock like 24 MHz oscillator.(CVE-2023-52882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: validate request buffer size in smb2_allocate_rsp_buf()\r\n\r\nThe response buffer should be allocated in smb2_allocate_rsp_buf\nbefore validating request. But the fields in payload as well as smb2 header\nis used in smb2_allocate_rsp_buf(). This patch add simple buffer size\nvalidation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses\r\n\r\nSince commit a4d5613c4dc6 (\u0026quot;arm: extend pfn_valid to take into account\nfreed memory map alignment\u0026quot;) changes the semantics of pfn_valid() to check\npresence of the memory map for a PFN. A valid page for an address which\nis reserved but not mapped by the kernel[1], the system crashed during\nsome uio test with the following memory layout:\r\n\r\n node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]\n node   0: [mem 0x00000000d0000000-0x00000000da1fffff]\n the uio layout is\uff1a0xc0900000, 0x100000\r\n\r\nthe crash backtrace like:\r\n\r\n  Unable to handle kernel paging request at virtual address bff00000\n  [...]\n  CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1\n  Hardware name: Generic DT based system\n  PC is at b15_flush_kern_dcache_area+0x24/0x3c\n  LR is at __sync_icache_dcache+0x6c/0x98\n  [...]\n   (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)\n   (__sync_icache_dcache) from (set_pte_at+0x28/0x54)\n   (set_pte_at) from (remap_pfn_range+0x1a0/0x274)\n   (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])\n   (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)\n   (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)\n   (__do_mmap_mm) from (do_mmap+0x50/0x58)\n   (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)\n   (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)\n   (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)\n  Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)\n  ---[ end trace 09cf0734c3805d52 ]---\n  Kernel panic - not syncing: Fatal exception\r\n\r\nSo check if PG_reserved was set to solve this issue.\r\n\r\n[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/(CVE-2024-26947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\r\n\r\nIf -\u0026gt;NameOffset of smb2_create_req is smaller than Buffer offset of\nsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.\nThis patch set the minimum value of the name offset to the buffer offset\nto validate name length of smb2_create_req().(CVE-2024-26954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: swap: fix race between free_swap_and_cache() and swapoff()\r\n\r\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread.  This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\r\n\r\nThis is a theoretical problem and I haven\u0026apos;t been able to provoke it from a\ntest case.  But there has been agreement based on code review that this is\npossible (see link below).\r\n\r\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff().  There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free.  This isn\u0026apos;t present in get_swap_device()\nbecause it doesn\u0026apos;t make sense in general due to the race between getting\nthe reference and swapoff.  So I\u0026apos;ve added an equivalent check directly in\nfree_swap_and_cache().\r\n\r\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\r\n\r\n--8\u0026lt;-----\r\n\r\n__swap_entry_free() might be the last user and result in\n\u0026quot;count == SWAP_HAS_CACHE\u0026quot;.\r\n\r\nswapoff-\u0026gt;try_to_unuse() will stop as soon as soon as si-\u0026gt;inuse_pages==0.\r\n\r\nSo the question is: could someone reclaim the folio and turn\nsi-\u0026gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().\r\n\r\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\r\n\r\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\r\n\r\nProcess 1 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\r\n\r\nProcess 2 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\r\n\r\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\r\n\r\n__try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt;\nput_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt;\nswap_entry_free()-\u0026gt;swap_range_free()-\u0026gt;\n...\nWRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries);\r\n\r\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\r\n\r\n--8\u0026lt;-----(CVE-2024-26960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Prevent deadlock while disabling aRFS\r\n\r\nWhen disabling aRFS under the `priv-\u0026gt;state_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\r\n\r\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker\u0026apos;s responsibility since\ndisabling aRFS deletes the rules.\r\n\r\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\r\n\r\nKernel log:\r\n\r\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G          I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\r\n\r\nbut task is already holding lock:\nffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nwhich lock already depends on the new lock.\r\n\r\nthe existing dependency chain (in reverse order) is:\r\n\r\n-\u0026gt; #1 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}:\n       __mutex_lock+0x80/0xc90\n       arfs_handle_work+0x4b/0x3b0 [mlx5_core]\n       process_one_work+0x1dc/0x4a0\n       worker_thread+0x1bf/0x3c0\n       kthread+0xd7/0x100\n       ret_from_fork+0x2d/0x50\n       ret_from_fork_asm+0x11/0x20\r\n\r\n-\u0026gt; #0 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}:\n       __lock_acquire+0x17b4/0x2c80\n       lock_acquire+0xd0/0x2b0\n       __flush_work+0x7a/0x4e0\n       __cancel_work_timer+0x131/0x1c0\n       arfs_del_rules+0x143/0x1e0 [mlx5_core]\n       mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n       mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n       ethnl_set_channels+0x28f/0x3b0\n       ethnl_default_set_doit+0xec/0x240\n       genl_family_rcv_msg_doit+0xd0/0x120\n       genl_rcv_msg+0x188/0x2c0\n       netlink_rcv_skb+0x54/0x100\n       genl_rcv+0x24/0x40\n       netlink_unicast+0x1a1/0x270\n       netlink_sendmsg+0x214/0x460\n       __sock_sendmsg+0x38/0x60\n       __sys_sendto+0x113/0x170\n       __x64_sys_sendto+0x20/0x30\n       do_syscall_64+0x40/0xe0\n       entry_SYSCALL_64_after_hwframe+0x46/0x4e\r\n\r\nother info that might help us debug this:\r\n\r\n Possible unsafe locking scenario:\r\n\r\n       CPU0                    CPU1\n       ----                    ----\n  lock(\u0026amp;priv-\u0026gt;state_lock);\n                               lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\n                               lock(\u0026amp;priv-\u0026gt;state_lock);\n  lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\r\n\r\n *** DEADLOCK ***\r\n\r\n3 locks held by ethtool/386089:\n #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n #2: ffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G          I        6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x60/0xa0\n check_noncircular+0x144/0x160\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n ? __flush_work+0x74/0x4e0\n ? save_trace+0x3e/0x360\n ? __flush_work+0x74/0x4e0\n __flush_work+0x7a/0x4e0\n ? __flush_work+0x74/0x4e0\n ? __lock_acquire+0xa78/0x2c80\n ? lock_acquire+0xd0/0x2b0\n ? mark_held_locks+0x49/0x70\n __cancel_work_timer+0x131/0x1c0\n ? mark_held_locks+0x49/0x70\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n ? ethn\n---truncated---(CVE-2024-27014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\r\n\r\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential NULL pointer dereferences in \u0026apos;dcn10_set_output_transfer_func()\u0026apos;\r\n\r\nThe \u0026apos;stream\u0026apos; pointer is used in dcn10_set_output_transfer_func() before\nthe check if \u0026apos;stream\u0026apos; is NULL.\r\n\r\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check \u0026apos;stream\u0026apos; (see line 1875)(CVE-2024-27044)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ll_temac: platform_get_resource replaced by wrong function\r\n\r\nThe function platform_get_resource was replaced with\ndevm_platform_ioremap_resource_byname and is called using 0 as name.\r\n\r\nThis eventually ends up in platform_get_resource_byname in the call\nstack, where it causes a null pointer in strcmp.\r\n\r\n\tif (type == resource_type(r) \u0026amp;\u0026amp; !strcmp(r-\u0026gt;name, name))\r\n\r\nIt should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion\r\n\r\nThe first kiocb_set_cancel_fn() argument may point at a struct kiocb\nthat is not embedded inside struct aio_kiocb. With the current code,\ndepending on the compiler, the req-\u0026gt;ki_ctx read happens either before\nthe IOCB_AIO_RW test or after that test. Move the req-\u0026gt;ki_ctx read such\nthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Use raw spinlock for cgr_lock\r\n\r\nsmp_call_function always runs its callback in hard IRQ context, even on\nPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock\nfor cgr_lock to ensure we aren\u0026apos;t waiting on a sleeping task.\r\n\r\nAlthough this bug has existed for a while, it was not apparent until\ncommit ef2a8d5478b9 (\u0026quot;net: dpaa: Adjust queue depth on rate change\u0026quot;)\nwhich invokes smp_call_function_single via qman_update_cgr_safe every\ntime a link goes up or down.(CVE-2024-35819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()\r\n\r\nIn the for statement of lbs_allocate_cmd_buffer(), if the allocation of\ncmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to\nbe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: bridge: replace physindev with physinif in nf_bridge_info\r\n\r\nAn skb can be added to a neigh-\u0026gt;arp_queue while waiting for an arp\nreply. Where original skb\u0026apos;s skb-\u0026gt;dev can be different to neigh\u0026apos;s\nneigh-\u0026gt;dev. For instance in case of bridging dnated skb from one veth to\nanother, the skb would be added to a neigh-\u0026gt;arp_queue of the bridge.\r\n\r\nAs skb-\u0026gt;dev can be reset back to nf_bridge-\u0026gt;physindev and used, and as\nthere is no explicit mechanism that prevents this physindev from been\nfreed under us (for instance neigh_flush_dev doesn\u0026apos;t cleanup skbs from\ndifferent device\u0026apos;s neigh queue) we can crash on e.g. this stack:\r\n\r\narp_process\n  neigh_update\n    skb = __skb_dequeue(\u0026amp;neigh-\u0026gt;arp_queue)\n      neigh_resolve_output(..., skb)\n        ...\n          br_nf_dev_xmit\n            br_nf_pre_routing_finish_bridge_slow\n              skb-\u0026gt;dev = nf_bridge-\u0026gt;physindev\n              br_handle_frame_finish\r\n\r\nLet\u0026apos;s use plain ifindex instead of net_device link. To peek into the\noriginal net_device we will use dev_get_by_index_rcu(). Thus either we\nget device and are safe to use it or we don\u0026apos;t get it and drop skb.(CVE-2024-35839)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix UAF in smb2_reconnect_server()\r\n\r\nThe UAF bug is due to smb2_reconnect_server() accessing a session that\nis already being teared down by another thread that is executing\n__cifs_put_smb_ses().  This can happen when (a) the client has\nconnection to the server but no session or (b) another thread ends up\nsetting @ses-\u0026gt;ses_status again to something different than\nSES_EXITING.\r\n\r\nTo fix this, we need to make sure to unconditionally set\n@ses-\u0026gt;ses_status to SES_EXITING and prevent any other threads from\nsetting a new status while we\u0026apos;re still tearing it down.\r\n\r\nThe following can be reproduced by adding some delay to right after\nthe ipc is freed in __cifs_put_smb_ses() - which will give\nsmb2_reconnect_server() worker a chance to run and then accessing\n@ses-\u0026gt;ipc:\r\n\r\nkinit ...\nmount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10\n[disconnect srv]\nls /mnt/1 \u0026amp;\u0026gt;/dev/null\nsleep 30\nkdestroy\n[reconnect srv]\nsleep 10\numount /mnt/1\n...\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\ngeneral protection fault, probably for non-canonical address\n0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39\n04/01/2014\nWorkqueue: cifsiod smb2_reconnect_server [cifs]\nRIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0\nCode: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad\nde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 \u0026lt;48\u0026gt; 8b 01 48 39 f8 75\n7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8\nRSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83\nRAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b\nRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800\nRBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000\nR13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000\nFS: 0000000000000000(0000) GS:ffff888157c00000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x36/0x90\n ? exc_general_protection+0x1c1/0x3f0\n ? asm_exc_general_protection+0x26/0x30\n ? __list_del_entry_valid_or_report+0x33/0xf0\n __cifs_put_smb_ses+0x1ae/0x500 [cifs]\n smb2_reconnect_server+0x4ed/0x710 [cifs]\n process_one_work+0x205/0x6b0\n worker_thread+0x191/0x360\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xe2/0x110\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-35870)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: fix use-after-free bugs caused by ax25_ds_del_timer\r\n\r\nWhen the ax25 device is detaching, the ax25_dev_device_down()\ncalls ax25_ds_del_timer() to cleanup the slave_timer. When\nthe timer handler is running, the ax25_ds_del_timer() that\ncalls del_timer() in it will return directly. As a result,\nthe use-after-free bugs could happen, one of the scenarios\nis shown below:\r\n\r\n      (Thread 1)          |      (Thread 2)\n                          | ax25_ds_timeout()\nax25_dev_device_down()    |\n  ax25_ds_del_timer()     |\n    del_timer()           |\n  ax25_dev_put() //FREE   |\n                          |  ax25_dev-\u0026gt; //USE\r\n\r\nIn order to mitigate bugs, when the device is detaching, use\ntimer_shutdown_sync() to stop the timer.(CVE-2024-35887)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: properly terminate timers for kernel sockets\r\n\r\nWe had various syzbot reports about tcp timers firing after\nthe corresponding netns has been dismantled.\r\n\r\nFortunately Josef Bacik could trigger the issue more often,\nand could test a patch I wrote two years ago.\r\n\r\nWhen TCP sockets are closed, we call inet_csk_clear_xmit_timers()\nto \u0026apos;stop\u0026apos; the timers.\r\n\r\ninet_csk_clear_xmit_timers() can be called from any context,\nincluding when socket lock is held.\nThis is the reason it uses sk_stop_timer(), aka del_timer().\nThis means that ongoing timers might finish much later.\r\n\r\nFor user sockets, this is fine because each running timer\nholds a reference on the socket, and the user socket holds\na reference on the netns.\r\n\r\nFor kernel sockets, we risk that the netns is freed before\ntimer can complete, because kernel sockets do not hold\nreference on the netns.\r\n\r\nThis patch adds inet_csk_clear_xmit_timers_sync() function\nthat using sk_stop_timer_sync() to make sure all timers\nare terminated before the kernel socket is released.\nModules using kernel sockets close them in their netns exit()\nhandler.\r\n\r\nAlso add sock_not_owned_by_me() helper to get LOCKDEP\nsupport : inet_csk_clear_xmit_timers_sync() must not be called\nwhile socket lock is held.\r\n\r\nIt is very possible we can revert in the future commit\n3a58f13a881e (\u0026quot;net: rds: acquire refcount on TCP sockets\u0026quot;)\nwhich attempted to solve the issue in rds only.\n(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)\r\n\r\nWe probably can remove the check_net() tests from\ntcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vc4: don\u0026apos;t check if plane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb\r\n\r\nCurrently, when using non-blocking commits, we can see the following\nkernel warning:\r\n\r\n[  110.908514] ------------[ cut here ]------------\n[  110.908529] refcount_t: underflow; use-after-free.\n[  110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0\n[  110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6\n[  110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G         C         6.1.66-v8+ #32\n[  110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[  110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  110.909132] pc : refcount_dec_not_one+0xb8/0xc0\n[  110.909152] lr : refcount_dec_not_one+0xb4/0xc0\n[  110.909170] sp : ffffffc00913b9c0\n[  110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60\n[  110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480\n[  110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78\n[  110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000\n[  110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004\n[  110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003\n[  110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00\n[  110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572\n[  110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000\n[  110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001\n[  110.909434] Call trace:\n[  110.909441]  refcount_dec_not_one+0xb8/0xc0\n[  110.909461]  vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]\n[  110.909903]  vc4_cleanup_fb+0x44/0x50 [vc4]\n[  110.910315]  drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]\n[  110.910669]  vc4_atomic_commit_tail+0x390/0x9dc [vc4]\n[  110.911079]  commit_tail+0xb0/0x164 [drm_kms_helper]\n[  110.911397]  drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]\n[  110.911716]  drm_atomic_commit+0xb0/0xdc [drm]\n[  110.912569]  drm_mode_atomic_ioctl+0x348/0x4b8 [drm]\n[  110.913330]  drm_ioctl_kernel+0xec/0x15c [drm]\n[  110.914091]  drm_ioctl+0x24c/0x3b0 [drm]\n[  110.914850]  __arm64_sys_ioctl+0x9c/0xd4\n[  110.914873]  invoke_syscall+0x4c/0x114\n[  110.914897]  el0_svc_common+0xd0/0x118\n[  110.914917]  do_el0_svc+0x38/0xd0\n[  110.914936]  el0_svc+0x30/0x8c\n[  110.914958]  el0t_64_sync_handler+0x84/0xf0\n[  110.914979]  el0t_64_sync+0x18c/0x190\n[  110.914996] ---[ end trace 0000000000000000 ]---\r\n\r\nThis happens because, although `prepare_fb` and `cleanup_fb` are\nperfectly balanced, we cannot guarantee consistency in the check\nplane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb. This means that sometimes we can increase\nthe refcount in `prepare_fb` and don\u0026apos;t decrease it in `cleanup_fb`. The\nopposite can also be true.\r\n\r\nIn fact, the struct drm_plane .state shouldn\u0026apos;t be accessed directly\nbut instead, the `drm_atomic_get_new_plane_state()` helper function should\nbe used. So, we could stick to this check, but using\n`drm_atomic_get_new_plane_state()`. But actually, this check is not re\n---truncated---(CVE-2024-35932)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: send: handle path ref underflow in header iterate_inode_ref()\r\n\r\nChange BUG_ON to proper error handling if building the path buffer\nfails. The pointers are not printed so we don\u0026apos;t accidentally leak kernel\naddresses.(CVE-2024-35935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: check A-MSDU format more carefully\r\n\r\nIf it looks like there\u0026apos;s another subframe in the A-MSDU\nbut the header isn\u0026apos;t fully there, we can end up reading\ndata out of bounds, only to discard later. Make this a\nbit more careful and check if the subframe header can\neven be present.(CVE-2024-35937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()\r\n\r\nSubject: [PATCH] drm/panfrost: Fix the error path in\n panfrost_mmu_map_fault_addr()\r\n\r\nIf some the pages or sgt allocation failed, we shouldn\u0026apos;t release the\npages ref we got earlier, otherwise we will end up with unbalanced\nget/put_pages() calls. We should instead leave everything in place\nand let the BO release function deal with extra cleanup when the object\nis destroyed, or let the fault handler try again next time it\u0026apos;s called.(CVE-2024-35951)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix not validating setsockopt user input\r\n\r\nCheck user input length before copying data.(CVE-2024-35965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: RFCOMM: Fix not validating setsockopt user input\r\n\r\nsyzbot reported rfcomm_sock_setsockopt_old() is copying data without\nchecking user input length.\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset\ninclude/linux/sockptr.h:49 [inline]\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr\ninclude/linux/sockptr.h:55 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old\nnet/bluetooth/rfcomm/sock.c:632 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70\nnet/bluetooth/rfcomm/sock.c:673\nRead of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: Avoid infinite loop trying to resize local TT\r\n\r\nIf the MTU of one of an attached interface becomes too small to transmit\nthe local translation table then it must be resized to fit inside all\nfragments (when enabled) or a single packet.\r\n\r\nBut if the MTU becomes too low to transmit even the header + the VLAN\nspecific part then the resizing of the local TT will never succeed. This\ncan for example happen when the usable space is 110 bytes and 11 VLANs are\non top of batman-adv. In this case, at least 116 byte would be needed.\nThere will just be an endless spam of\r\n\r\n   batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)\r\n\r\nin the log but the function will never finish. Problem here is that the\ntimeout will be halved all the time and will then stagnate at 0 and\ntherefore never be able to reduce the table even more.\r\n\r\nThere are other scenarios possible with a similar result. The number of\nBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too\nhigh to fit inside a packet. Such a scenario can therefore happen also with\nonly a single VLAN + 7 non-purgable addresses - requiring at least 120\nbytes.\r\n\r\nWhile this should be handled proactively when:\r\n\r\n* interface with too low MTU is added\n* VLAN is added\n* non-purgeable local mac is added\n* MTU of an attached interface is reduced\n* fragmentation setting gets disabled (which most likely requires dropping\n  attached interfaces)\r\n\r\nnot all of these scenarios can be prevented because batman-adv is only\nconsuming events without the the possibility to prevent these actions\n(non-purgable MAC address added, MTU of an attached interface is reduced).\nIt is therefore necessary to also make sure that the code is able to handle\nalso the situations when there were already incompatible system\nconfiguration are present.(CVE-2024-35982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: fix possible out-of-bounds in gsm0_receive()\r\n\r\nAssuming the following:\n- side A configures the n_gsm in basic option mode\n- side B sends the header of a basic option mode frame with data length 1\n- side A switches to advanced option mode\n- side B sends 2 data bytes which exceeds gsm-\u0026gt;len\n  Reason: gsm-\u0026gt;len is not used in advanced option mode.\n- side A switches to basic option mode\n- side B keeps sending until gsm0_receive() writes past gsm-\u0026gt;buf\n  Reason: Neither gsm-\u0026gt;state nor gsm-\u0026gt;len have been reset after\n  reconfiguration.\r\n\r\nFix this by changing gsm-\u0026gt;count to gsm-\u0026gt;len comparison from equal to less\nthan. Also add upper limit checks against the constant MAX_MRU in\ngsm0_receive() and gsm1_receive() to harden against memory corruption of\ngsm-\u0026gt;len and gsm-\u0026gt;mru.\r\n\r\nAll other checks remain as we still need to limit the data according to the\nuser configuration and actual payload size.(CVE-2024-36016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-iocost: avoid out of bounds shift\r\n\r\nUBSAN catches undefined behavior in blk-iocost, where sometimes\niocg-\u0026gt;delay is shifted right by a number that is too large,\nresulting in undefined behavior on some architectures.\r\n\r\n[  186.556576] ------------[ cut here ]------------\nUBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23\nshift exponent 64 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;)\nCPU: 16 PID: 0 Comm: swapper/16 Tainted: G S          E    N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1\nHardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x8f/0xe0\n __ubsan_handle_shift_out_of_bounds+0x22c/0x280\n iocg_kick_delay+0x30b/0x310\n ioc_timer_fn+0x2fb/0x1f80\n __run_timer_base+0x1b6/0x250\n...\r\n\r\nAvoid that undefined behavior by simply taking the\n\u0026quot;delay = 0\u0026quot; branch if the shift is too large.\r\n\r\nI am not sure what the symptoms of an undefined value\ndelay will be, but I suspect it could be more than a\nlittle annoying to debug.(CVE-2024-36916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: fix overflow in blk_ioctl_discard()\r\n\r\nThere is no check for overflow of \u0026apos;start + len\u0026apos; in blk_ioctl_discard().\nHung task occurs if submit an discard ioctl with the following param:\n  start = 0x80000000000ff000, len = 0x8000000000fff000;\nAdd the overflow validation now.(CVE-2024-36917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\r\n\r\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won\u0026apos;t be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\r\n\r\nThis will suppress following BUG_ON():\r\n\r\n[  449.843143] ------------[ cut here ]------------\n[  449.848302] kernel BUG at mm/vmalloc.c:2727!\n[  449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[  449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[  449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[  449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[  449.882910] RIP: 0010:vunmap+0x2e/0x30\n[  449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 \u0026lt;0f\u0026gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[  449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[  449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[  449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[  449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[  449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[  449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[  449.953701] FS:  0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[  449.962732] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[  449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  449.993028] Call Trace:\n[  449.995756]  __iommu_dma_free+0x96/0x100\n[  450.000139]  bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[  450.006171]  bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[  450.011910]  bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[  450.018136]  fc_rport_work+0x103/0x5b0 [libfc]\n[  450.023103]  process_one_work+0x1e8/0x3c0\n[  450.027581]  worker_thread+0x50/0x3b0\n[  450.031669]  ? rescuer_thread+0x370/0x370\n[  450.036143]  kthread+0x149/0x170\n[  450.039744]  ? set_kthread_struct+0x40/0x40\n[  450.044411]  ret_from_fork+0x22/0x30\n[  450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[  450.048497]  libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[  450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/qeth: Fix kernel panic after setting hsuid\r\n\r\nSymptom:\nWhen the hsuid attribute is set for the first time on an IQD Layer3\ndevice while the corresponding network interface is already UP,\nthe kernel will try to execute a napi function pointer that is NULL.\r\n\r\nExample:\n---------------------------------------------------------------------------\n[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP\n[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6\nnft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de\ns_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod\n qdio ccwgroup pkey zcrypt\n[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1\n[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)\n[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)\n[ 2057.572748]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3\n[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000\n[ 2057.572754]            00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80\n[ 2057.572756]            000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8\n[ 2057.572758]            00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68\n[ 2057.572762] Krnl Code:#0000000000000000: 0000                illegal\n                         \u0026gt;0000000000000002: 0000                illegal\n                          0000000000000004: 0000                illegal\n                          0000000000000006: 0000                illegal\n                          0000000000000008: 0000                illegal\n                          000000000000000a: 0000                illegal\n                          000000000000000c: 0000                illegal\n                          000000000000000e: 0000                illegal\n[ 2057.572800] Call Trace:\n[ 2057.572801] ([\u0026lt;00000000ec639700\u0026gt;] 0xec639700)\n[ 2057.572803]  [\u0026lt;00000000913183e2\u0026gt;] net_rx_action+0x2ba/0x398\n[ 2057.572809]  [\u0026lt;0000000091515f76\u0026gt;] __do_softirq+0x11e/0x3a0\n[ 2057.572813]  [\u0026lt;0000000090ce160c\u0026gt;] do_softirq_own_stack+0x3c/0x58\n[ 2057.572817] ([\u0026lt;0000000090d2cbd6\u0026gt;] do_softirq.part.1+0x56/0x60)\n[ 2057.572822]  [\u0026lt;0000000090d2cc60\u0026gt;] __local_bh_enable_ip+0x80/0x98\n[ 2057.572825]  [\u0026lt;0000000091314706\u0026gt;] __dev_queue_xmit+0x2be/0xd70\n[ 2057.572827]  [\u0026lt;000003ff803dd6d6\u0026gt;] afiucv_hs_send+0x24e/0x300 [af_iucv]\n[ 2057.572830]  [\u0026lt;000003ff803dd88a\u0026gt;] iucv_send_ctrl+0x102/0x138 [af_iucv]\n[ 2057.572833]  [\u0026lt;000003ff803de72a\u0026gt;] iucv_sock_connect+0x37a/0x468 [af_iucv]\n[ 2057.572835]  [\u0026lt;00000000912e7e90\u0026gt;] __sys_connect+0xa0/0xd8\n[ 2057.572839]  [\u0026lt;00000000912e9580\u0026gt;] sys_socketcall+0x228/0x348\n[ 2057.572841]  [\u0026lt;0000000091514e1a\u0026gt;] system_call+0x2a6/0x2c8\n[ 2057.572843] Last Breaking-Event-Address:\n[ 2057.572844]  [\u0026lt;0000000091317e44\u0026gt;] __napi_poll+0x4c/0x1d8\n[ 2057.572846]\n[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt\n-------------------------------------------------------------------------------------------\r\n\r\nAnalysis:\nThere is one napi structure per out_q: card-\u0026gt;qdio.out_qs[i].napi\nThe napi.poll functions are set during qeth_open().\r\n\r\nSince\ncommit 1cfef80d4c2b (\u0026quot;s390/qeth: Don\u0026apos;t call dev_close/dev_open (DOWN/UP)\u0026quot;)\nqeth_set_offline()/qeth_set_online() no longer call dev_close()/\ndev_open(). So if qeth_free_qdio_queues() cleared\ncard-\u0026gt;qdio.out_qs[i].napi.poll while the network interface was UP and the\ncard was offline, they are not set again.\r\n\r\nReproduction:\nchzdev -e $devno layer2=0\nip link set dev $network_interface up\necho 0 \u0026gt; /sys/bus/ccw\n---truncated---(CVE-2024-36928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Move NPIV\u0026apos;s transport unregistration to after resource clean up\r\n\r\nThere are cases after NPIV deletion where the fabric switch still believes\nthe NPIV is logged into the fabric.  This occurs when a vport is\nunregistered before the Remove All DA_ID CT and LOGO ELS are sent to the\nfabric.\r\n\r\nCurrently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including\nthe fabric D_ID, removes the last ndlp reference and frees the ndlp rport\nobject.  This sometimes causes the race condition where the final DA_ID and\nLOGO are skipped from being sent to the fabric switch.\r\n\r\nFix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID\nand LOGO are sent.(CVE-2024-36952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix a possible memleak in tipc_buf_append\r\n\r\n__skb_linearize() doesn\u0026apos;t free the skb when it fails, so move\n\u0026apos;*buf = NULL\u0026apos; after __skb_linearize(), so that the skb can be\nfreed on the err path.(CVE-2024-36954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix invalid reads in fence signaled events\r\n\r\nCorrectly set the length of the drm_event to the size of the structure\nthat\u0026apos;s actually used.\r\n\r\nThe length of the drm_event was set to the parent structure instead of\nto the drm_vmw_event_fence which is supposed to be read. drm_read\nuses the length parameter to copy the event to the user space thus\nresuling in oob reads.(CVE-2024-36960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()\r\n\r\nl2cap_le_flowctl_init() can cause both div-by-zero and an integer\noverflow since hdev-\u0026gt;le_mtu may not fall in the valid range.\r\n\r\nMove MTU from hci_dev to hci_conn to validate MTU and stop the connection\nprocess earlier if MTU is invalid.\nAlso, add a missing validation in read_buffer_size() and make it return\nan error value if the validation fails.\nNow hci_conn_add() returns ERR_PTR() as it can fail due to the both a\nkzalloc failure and invalid MTU value.\r\n\r\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nWorkqueue: hci0 hci_rx_work\nRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547\nCode: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c\n89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 \u0026lt;66\u0026gt; f7 f3 89 c3 ff c3 4d 8d\nb7 88 00 00 00 4c 89 f0 48 c1 e8 03 42\nRSP: 0018:ffff88810bc0f858 EFLAGS: 00010246\nRAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f\nRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa\nR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084\nR13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000\nFS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]\n l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]\n l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]\n l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809\n l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506\n hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]\n hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335\n worker_thread+0x926/0xe70 kernel/workqueue.c:3416\n kthread+0x2e3/0x380 kernel/kthread.c:388\n ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---(CVE-2024-36968)\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)",
  "id": "OESA-2024-1737",
  "modified": "2026-08-06T11:07:12Z",
  "published": "2024-06-21T11:07:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47366"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48693"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52670"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52672"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52693"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52708"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52732"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52762"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52810"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52841"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52846"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52882"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26936"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27044"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35796"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35815"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35819"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35839"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35870"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35887"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35910"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35932"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35935"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35937"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35951"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35966"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36916"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36917"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36919"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36928"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36971"
    }
  ],
  "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-47366",
    "CVE-2022-48673",
    "CVE-2022-48693",
    "CVE-2023-52670",
    "CVE-2023-52672",
    "CVE-2023-52693",
    "CVE-2023-52708",
    "CVE-2023-52732",
    "CVE-2023-52739",
    "CVE-2023-52747",
    "CVE-2023-52762",
    "CVE-2023-52810",
    "CVE-2023-52821",
    "CVE-2023-52841",
    "CVE-2023-52846",
    "CVE-2023-52882",
    "CVE-2024-26936",
    "CVE-2024-26947",
    "CVE-2024-26954",
    "CVE-2024-26960",
    "CVE-2024-27014",
    "CVE-2024-27019",
    "CVE-2024-27044",
    "CVE-2024-35796",
    "CVE-2024-35815",
    "CVE-2024-35819",
    "CVE-2024-35828",
    "CVE-2024-35839",
    "CVE-2024-35870",
    "CVE-2024-35887",
    "CVE-2024-35910",
    "CVE-2024-35932",
    "CVE-2024-35935",
    "CVE-2024-35937",
    "CVE-2024-35951",
    "CVE-2024-35965",
    "CVE-2024-35966",
    "CVE-2024-35982",
    "CVE-2024-36016",
    "CVE-2024-36916",
    "CVE-2024-36917",
    "CVE-2024-36919",
    "CVE-2024-36928",
    "CVE-2024-36952",
    "CVE-2024-36954",
    "CVE-2024-36960",
    "CVE-2024-36968",
    "CVE-2024-36971"
  ]
}

RHSA-2024:5101

Vulnerability from csaf_opensuse - Published: 2024-08-08 00:00 - Updated: 2026-09-20 11:41

Summary

security update for kernel

Severity

Important

Scope

170 vulnerabilities in this advisory, including CVE-2024-36954.

CVE-2024-36954

4.7 (Medium)


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

Recommended: 20 products

Open the full advisory

RHSA-2024:5102

Vulnerability from csaf_redhat - Published: 2024-08-08 04:44 - Updated: 2026-09-13 08:28

Summary

Red Hat Security Advisory: kernel-rt security update

Severity

Important

Scope

149 vulnerabilities in this advisory, including CVE-2024-36954.

CVE-2024-36954

5.5 (Medium)


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

Fixed: 30 products

https://access.redhat.com/errata/RHSA-2024:5102

Open the full advisory

RHSA-2025:1658

Vulnerability from csaf_redhat - Published: 2025-02-19 01:00 - Updated: 2026-09-14 12:25

Summary

Red Hat Security Advisory: kernel security update

Severity

Moderate

Scope

17 vulnerabilities in this advisory, including CVE-2024-36954.

CVE-2024-36954

5.5 (Medium)


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

Fixed: 279 products

https://access.redhat.com/errata/RHSA-2025:1658

Open the full advisory

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-2024-36954.

CVE-2024-36954

0.0 (None)


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

Known affected: 2 products Known not affected: 1 product

https://support.industry.siemens.com/cs/ww/en/view/109977557/

Open the full advisory

SUSE-SU-2024:1979-1

Vulnerability from csaf_suse - Published: 2024-06-11 07:41 - Updated: 2026-09-20 15:53

Summary

Security update for the Linux Kernel

Severity

Important

Scope

180 vulnerabilities in this advisory, including CVE-2024-36954.

CVE-2024-36954

4.7 (Medium)


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

Recommended: 18 products

Open the full advisory

SUSE-SU-2024:1983-1

Vulnerability from csaf_suse - Published: 2024-06-11 10:56 - Updated: 2026-09-20 15:53

Summary

Security update for the Linux Kernel

Severity

Important

Scope

199 vulnerabilities in this advisory, including CVE-2024-36954.

CVE-2024-36954

4.7 (Medium)


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

Recommended: 12 products

Open the full advisory

SUSE-SU-2024:2184-1

Vulnerability from csaf_suse - Published: 2024-06-24 18:34 - Updated: 2026-09-20 15:55

Summary

Security update for the Linux Kernel

Severity

Important

Scope

198 vulnerabilities in this advisory, including CVE-2024-36954.

CVE-2024-36954

4.7 (Medium)


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

Recommended: 57 products

Open the full advisory

SUSE-SU-2024:4314-1

Vulnerability from csaf_suse - Published: 2024-12-13 15:23 - Updated: 2026-09-20 17:14

Summary

Security update for the Linux Kernel

Severity

Important

Scope

241 vulnerabilities in this advisory, including CVE-2024-36954.

CVE-2024-36954

4.7 (Medium)


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

Recommended: 41 products

Open the full advisory

SUSE-SU-2024:4315-1

Vulnerability from csaf_suse - Published: 2024-12-13 15:23 - Updated: 2026-09-20 17:14

Summary

Security update for the Linux Kernel

Severity

Important

Scope

230 vulnerabilities in this advisory, including CVE-2024-36954.

CVE-2024-36954

4.7 (Medium)


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

Recommended: 49 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-2024-36954 (GCVE-0-2024-36954)

OESA-2024-1737 (CVE-2021-47366)

Example:

Tags

Sightings

Nomenclature

Related by attack behaviour