Vulnerability-Lookup

CVE-2024-38586 (GCVE-0-2024-38586)

Vulnerability from cvelistv5 – Published: 2024-06-19 13:37 – Updated: 2026-05-11 20:19

Title

r8169: Fix possible ring buffer corruption on fragmented Tx packets.

Summary

In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.

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:13 UTC

Assigner

Linux CNA under the mitre root

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

References

7 references

URL	Tags
https://git.kernel.org/stable/c/61c1c98e2607120ce…
https://git.kernel.org/stable/c/b6d21cf40de103d63…
https://git.kernel.org/stable/c/0c48185a953095567…
https://git.kernel.org/stable/c/68222d7b4b72aa321…
https://git.kernel.org/stable/c/078d5b7500d70af2d…
https://git.kernel.org/stable/c/54e7a0d111240c92c…
https://git.kernel.org/stable/c/c71e3a5cffd5309d7…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 9020845fb5d6bb4876a38fdf1259600e7d9a63d4 , < 61c1c98e2607120ce9c3fa1bf75e6da909712b27 (git) Affected: 9020845fb5d6bb4876a38fdf1259600e7d9a63d4 , < b6d21cf40de103d63ae78551098a7c06af8c98dd (git) Affected: 9020845fb5d6bb4876a38fdf1259600e7d9a63d4 , < 0c48185a95309556725f818b82120bb74e9c627d (git) Affected: 9020845fb5d6bb4876a38fdf1259600e7d9a63d4 , < 68222d7b4b72aa321135cd453dac37f00ec41fd1 (git) Affected: 9020845fb5d6bb4876a38fdf1259600e7d9a63d4 , < 078d5b7500d70af2de6b38e226b03f0b932026a6 (git) Affected: 9020845fb5d6bb4876a38fdf1259600e7d9a63d4 , < 54e7a0d111240c92c0f02ceba6eb8f26bf6d6479 (git) Affected: 9020845fb5d6bb4876a38fdf1259600e7d9a63d4 , < c71e3a5cffd5309d7f84444df03d5b72600cc417 (git)	guessed
Linux	Linux	Affected: 5.7 Unaffected: 0 , < 5.7 (semver) Unaffected: 5.10.221 , ≤ 5.10.* (semver) Unaffected: 5.15.161 , ≤ 5.15.* (semver) Unaffected: 6.1.93 , ≤ 6.1.* (semver) Unaffected: 6.6.33 , ≤ 6.6.* (semver) Unaffected: 6.8.12 , ≤ 6.8.* (semver) Unaffected: 6.9.3 , ≤ 6.9.* (semver) Unaffected: 6.10 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T04:12:25.972Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-38586",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T17:13:50.332760Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-11T17:34:55.087Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/realtek/r8169_main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "61c1c98e2607120ce9c3fa1bf75e6da909712b27",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "b6d21cf40de103d63ae78551098a7c06af8c98dd",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "0c48185a95309556725f818b82120bb74e9c627d",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "68222d7b4b72aa321135cd453dac37f00ec41fd1",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "078d5b7500d70af2de6b38e226b03f0b932026a6",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "54e7a0d111240c92c0f02ceba6eb8f26bf6d6479",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "c71e3a5cffd5309d7f84444df03d5b72600cc417",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/realtek/r8169_main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.7"
            },
            {
              "lessThan": "5.7",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.221",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.161",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.93",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.33",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.9.*",
              "status": "unaffected",
              "version": "6.9.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.10",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.221",
                  "versionStartIncluding": "5.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.161",
                  "versionStartIncluding": "5.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.93",
                  "versionStartIncluding": "5.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.33",
                  "versionStartIncluding": "5.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.8.12",
                  "versionStartIncluding": "5.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.9.3",
                  "versionStartIncluding": "5.7",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.10",
                  "versionStartIncluding": "5.7",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\n\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\n\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\n\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:19:35.312Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27"
        },
        {
          "url": "https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd"
        },
        {
          "url": "https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d"
        },
        {
          "url": "https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1"
        },
        {
          "url": "https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6"
        },
        {
          "url": "https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479"
        },
        {
          "url": "https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417"
        }
      ],
      "title": "r8169: Fix possible ring buffer corruption on fragmented Tx packets.",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-38586",
    "datePublished": "2024-06-19T13:37:41.879Z",
    "dateReserved": "2024-06-18T19:36:34.929Z",
    "dateUpdated": "2026-05-11T20:19:35.312Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-38586",
      "date": "2026-11-10",
      "epss": "0.00252",
      "percentile": "0.16779"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/net/ethernet/realtek/r8169_main.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "61c1c98e2607120ce9c3fa1bf75e6da909712b27",
                    "status": "affected",
                    "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "b6d21cf40de103d63ae78551098a7c06af8c98dd",
                    "status": "affected",
                    "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "0c48185a95309556725f818b82120bb74e9c627d",
                    "status": "affected",
                    "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "68222d7b4b72aa321135cd453dac37f00ec41fd1",
                    "status": "affected",
                    "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "078d5b7500d70af2de6b38e226b03f0b932026a6",
                    "status": "affected",
                    "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "54e7a0d111240c92c0f02ceba6eb8f26bf6d6479",
                    "status": "affected",
                    "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "c71e3a5cffd5309d7f84444df03d5b72600cc417",
                    "status": "affected",
                    "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/net/ethernet/realtek/r8169_main.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "5.7"
                  },
                  {
                    "lessThan": "5.7",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.221",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.161",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.93",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.33",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.8.*",
                    "status": "unaffected",
                    "version": "6.8.12",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.9.*",
                    "status": "unaffected",
                    "version": "6.9.3",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "6.10",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "E0EDF2FF-6296-424A-A458-E113598FCEF6",
                    "versionEndExcluding": "5.10.221",
                    "versionStartIncluding": "5.7",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "31130639-53FE-4726-8986-434EE2528CB2",
                    "versionEndExcluding": "5.15.161",
                    "versionStartIncluding": "5.11",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "EEFB78EE-F990-4197-BF1C-156760A55667",
                    "versionEndExcluding": "6.1.93",
                    "versionStartIncluding": "5.16",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "FCE796DF-3B50-4DC6-BAE5-95271068FC9E",
                    "versionEndExcluding": "6.6.33",
                    "versionStartIncluding": "6.2",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "80550309-67AB-4FD1-AC07-3DED5C4F01B2",
                    "versionEndExcluding": "6.8.12",
                    "versionStartIncluding": "6.7",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "E07124C1-19E8-4D21-828D-9932A01D3011",
                    "versionEndExcluding": "6.9.3",
                    "versionStartIncluding": "6.9",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\n\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\n\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\n\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: r8169: corrige una posible corrupci\u00f3n del b\u00fafer en anillo en paquetes Tx fragmentados. Se encontr\u00f3 un problema en el RTL8125b al transmitir peque\u00f1os paquetes fragmentados, por el cual se insertaban entradas no v\u00e1lidas en el b\u00fafer del anillo de transmisi\u00f3n, lo que posteriormente generaba llamadas a dma_unmap_single() con una direcci\u00f3n nula. Esto se debi\u00f3 a que rtl8169_start_xmit() no not\u00f3 los cambios en nr_frags que pueden ocurrir cuando se rellenan paquetes peque\u00f1os (para evitar peculiaridades del hardware) en rtl8169_tso_csum_v2(). Para solucionar este problema, posponga la inspecci\u00f3n de nr_frags hasta que se haya aplicado el relleno."
          }
        ],
        "id": "CVE-2024-38586",
        "lastModified": "2026-06-17T07:40:38.830",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2024-38586",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T17:13:50.332760Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-06-19T14:15:18.700",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-787"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-11-05T12:28:53+00:00",
      "cve": "CVE-2024-38586",
      "id": "CVE-2024-38586",
      "initial_release_date": "2024-06-19T00:00:00+00:00",
      "product_status:fixed": "927",
      "product_status:known_affected": "22",
      "product_status:known_not_affected": "45",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: r8169: Fix possible ring buffer corruption on fragmented Tx packets.",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-38586.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "providerMetadata": {
              "dateUpdated": "2024-08-02T04:12:25.972Z",
              "orgId": "af854a3a-2127-422b-91ae-364da2661108",
              "shortName": "CVE"
            },
            "references": [
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417"
              }
            ],
            "title": "CVE Program Container"
          },
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2024-38586",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-09-10T17:13:50.332760Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-09-11T12:42:26.816Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "drivers/net/ethernet/realtek/r8169_main.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "61c1c98e2607",
                  "status": "affected",
                  "version": "9020845fb5d6",
                  "versionType": "git"
                },
                {
                  "lessThan": "b6d21cf40de1",
                  "status": "affected",
                  "version": "9020845fb5d6",
                  "versionType": "git"
                },
                {
                  "lessThan": "0c48185a9530",
                  "status": "affected",
                  "version": "9020845fb5d6",
                  "versionType": "git"
                },
                {
                  "lessThan": "68222d7b4b72",
                  "status": "affected",
                  "version": "9020845fb5d6",
                  "versionType": "git"
                },
                {
                  "lessThan": "078d5b7500d7",
                  "status": "affected",
                  "version": "9020845fb5d6",
                  "versionType": "git"
                },
                {
                  "lessThan": "54e7a0d11124",
                  "status": "affected",
                  "version": "9020845fb5d6",
                  "versionType": "git"
                },
                {
                  "lessThan": "c71e3a5cffd5",
                  "status": "affected",
                  "version": "9020845fb5d6",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "drivers/net/ethernet/realtek/r8169_main.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "5.7"
                },
                {
                  "lessThan": "5.7",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.10.*",
                  "status": "unaffected",
                  "version": "5.10.221",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.15.*",
                  "status": "unaffected",
                  "version": "5.15.161",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.1.*",
                  "status": "unaffected",
                  "version": "6.1.93",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.33",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.8.*",
                  "status": "unaffected",
                  "version": "6.8.12",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.9.*",
                  "status": "unaffected",
                  "version": "6.9.3",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "6.10",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\n\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\n\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\n\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied."
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2024-11-05T09:30:24.574Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27"
            },
            {
              "url": "https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd"
            },
            {
              "url": "https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d"
            },
            {
              "url": "https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1"
            },
            {
              "url": "https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6"
            },
            {
              "url": "https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479"
            },
            {
              "url": "https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417"
            }
          ],
          "title": "r8169: Fix possible ring buffer corruption on fragmented Tx packets.",
          "x_generator": {
            "engine": "bippy-9e1c9544281a"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2024-38586",
        "datePublished": "2024-06-19T13:37:41.879Z",
        "dateReserved": "2024-06-18T19:36:34.929Z",
        "dateUpdated": "2024-11-05T09:30:24.574Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}

FKIE_CVE-2024-38586

Vulnerability from fkie_nvd - Published: 2024-06-19 14:15 - Updated: 2026-06-17 07:40

Severity

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

Summary

References

URL	Tags
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417	Patch
af854a3a-2127-422b-91ae-364da2661108	https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6	Patch
af854a3a-2127-422b-91ae-364da2661108	https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d	Patch
af854a3a-2127-422b-91ae-364da2661108	https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479	Patch
af854a3a-2127-422b-91ae-364da2661108	https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27	Patch
af854a3a-2127-422b-91ae-364da2661108	https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1	Patch
af854a3a-2127-422b-91ae-364da2661108	https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd	Patch
af854a3a-2127-422b-91ae-364da2661108	https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417	Patch

Impacted products

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

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/realtek/r8169_main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "61c1c98e2607120ce9c3fa1bf75e6da909712b27",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "b6d21cf40de103d63ae78551098a7c06af8c98dd",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "0c48185a95309556725f818b82120bb74e9c627d",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "68222d7b4b72aa321135cd453dac37f00ec41fd1",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "078d5b7500d70af2de6b38e226b03f0b932026a6",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "54e7a0d111240c92c0f02ceba6eb8f26bf6d6479",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            },
            {
              "lessThan": "c71e3a5cffd5309d7f84444df03d5b72600cc417",
              "status": "affected",
              "version": "9020845fb5d6bb4876a38fdf1259600e7d9a63d4",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/realtek/r8169_main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.7"
            },
            {
              "lessThan": "5.7",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.221",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.161",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.93",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.33",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.9.*",
              "status": "unaffected",
              "version": "6.9.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.10",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "E0EDF2FF-6296-424A-A458-E113598FCEF6",
              "versionEndExcluding": "5.10.221",
              "versionStartIncluding": "5.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "31130639-53FE-4726-8986-434EE2528CB2",
              "versionEndExcluding": "5.15.161",
              "versionStartIncluding": "5.11",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "EEFB78EE-F990-4197-BF1C-156760A55667",
              "versionEndExcluding": "6.1.93",
              "versionStartIncluding": "5.16",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "FCE796DF-3B50-4DC6-BAE5-95271068FC9E",
              "versionEndExcluding": "6.6.33",
              "versionStartIncluding": "6.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "80550309-67AB-4FD1-AC07-3DED5C4F01B2",
              "versionEndExcluding": "6.8.12",
              "versionStartIncluding": "6.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "E07124C1-19E8-4D21-828D-9932A01D3011",
              "versionEndExcluding": "6.9.3",
              "versionStartIncluding": "6.9",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\n\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\n\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\n\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: r8169: corrige una posible corrupci\u00f3n del b\u00fafer en anillo en paquetes Tx fragmentados. Se encontr\u00f3 un problema en el RTL8125b al transmitir peque\u00f1os paquetes fragmentados, por el cual se insertaban entradas no v\u00e1lidas en el b\u00fafer del anillo de transmisi\u00f3n, lo que posteriormente generaba llamadas a dma_unmap_single() con una direcci\u00f3n nula. Esto se debi\u00f3 a que rtl8169_start_xmit() no not\u00f3 los cambios en nr_frags que pueden ocurrir cuando se rellenan paquetes peque\u00f1os (para evitar peculiaridades del hardware) en rtl8169_tso_csum_v2(). Para solucionar este problema, posponga la inspecci\u00f3n de nr_frags hasta que se haya aplicado el relleno."
    }
  ],
  "id": "CVE-2024-38586",
  "lastModified": "2026-06-17T07:40:38.830",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2024-38586",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2024-09-10T17:13:50.332760Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-06-19T14:15:18.700",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-787"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

GHSA-6F25-FXW5-F5MV

Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2025-09-17 21:30

Details

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

r8169: Fix possible ring buffer corruption on fragmented Tx packets.

An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address.

This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2().

To fix this, postpone inspecting nr_frags until after any padding has been applied.

Severity

7.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-38586"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-19T14:15:18Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\n\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\n\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\n\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied.",
  "id": "GHSA-6f25-fxw5-f5mv",
  "modified": "2025-09-17T21:30:40Z",
  "published": "2024-06-19T15:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38586"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b72600cc417"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

ICSA-25-226-07

Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00

Summary

Siemens Third-Party Components in SINEC OS

Scope

486 vulnerabilities in this advisory, including CVE-2024-38586.

CVE-2024-38586

Known not affected: 3 products

Open the full advisory

ICSA-25-226-15

Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00

Summary

Siemens SINEC OS

Scope

381 vulnerabilities in this advisory, including CVE-2024-38586.

CVE-2024-38586

4.7 (Medium)


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

Known affected: 2 products Known not affected: 1 product

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

Open the full advisory

OESA-2024-1860 (CVE-2021-47391)

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

RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests

The FSM can run in a circle allowing rdma_resolve_ip() to be called twice on the same id_priv. While this cannot happen without going through the work, it violates the invariant that the same address resolution background request cannot be active twice.

   CPU 1                                  CPU 2

rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1

         process_one_req(): for #1
                      addr_handler():
                        RDMA_CM_ADDR_QUERY -&gt; RDMA_CM_ADDR_BOUND
                        mutex_unlock(&amp;id_priv-&gt;handler_mutex);
                        [.. handler still running ..]

rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) !! two requests are now on the req_list

rdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation(): rdma_addr_cancel()

                      // process_one_req() self removes it
              spin_lock_bh(&amp;lock);
                       cancel_delayed_work(&amp;req-&gt;work);
                   if (!list_empty(&amp;req-&gt;list)) == true

  ! rdma_addr_cancel() returns after process_on_req #1 is done

kfree(id_priv)

         process_one_req(): for #2
                      addr_handler():
                    mutex_lock(&amp;id_priv-&gt;handler_mutex);
                        !! Use after free on id_priv

rdma_addr_cancel() expects there to be one req on the list and only cancels the first one. The self-removal behavior of the work only happens after the handler has returned. This yields a situations where the req_list can have two reqs for the same "handle" but rdma_addr_cancel() only cancels the first one.

The second req remains active beyond rdma_destroy_id() and will use-after-free id_priv once it inevitably triggers.

Fix this by remembering if the id_priv has called rdma_resolve_ip() and always cancel before calling it again. This ensures the req_list never gets more than one item in it and doesn't cost anything in the normal flow that never uses this strange error path.(CVE-2021-47391)

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

net/smc: Forward wakeup to smc socket waitqueue after fallback

When we replace TCP with SMC and a fallback occurs, there may be some socket waitqueue entries remaining in smc socket->wq, such as eppoll_entries inserted by userspace applications.

After the fallback, data flows over TCP/IP and only clcsocket->wq will be woken up. Applications can't be notified by the entries which were inserted in smc socket->wq before fallback. So we need a mechanism to wake up smc socket->wq at the same time if some entries remaining in it.

The current workaround is to transfer the entries from smc socket->wq to clcsock->wq during the fallback. But this may cause a crash like this:

general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107 RIP: 0010:__wake_up_common+0x65/0x170 Call Trace: <IRQ> __wake_up_common_lock+0x7a/0xc0 sock_def_readable+0x3c/0x70 tcp_data_queue+0x4a7/0xc40 tcp_rcv_established+0x32f/0x660 ? sk_filter_trim_cap+0xcb/0x2e0 tcp_v4_do_rcv+0x10b/0x260 tcp_v4_rcv+0xd2a/0xde0 ip_protocol_deliver_rcu+0x3b/0x1d0 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0x6a/0x110 ? tcp_v4_early_demux+0xa2/0x140 ? tcp_v4_early_demux+0x10d/0x140 ip_sublist_rcv_finish+0x49/0x60 ip_sublist_rcv+0x19d/0x230 ip_list_rcv+0x13e/0x170 __netif_receive_skb_list_core+0x1c2/0x240 netif_receive_skb_list_internal+0x1e6/0x320 napi_complete_done+0x11d/0x190 mlx5e_napi_poll+0x163/0x6b0 [mlx5_core] __napi_poll+0x3c/0x1b0 net_rx_action+0x27c/0x300 __do_softirq+0x114/0x2d2 irq_exit_rcu+0xb4/0xe0 common_interrupt+0xba/0xe0 </IRQ> <TASK>

The crash is caused by privately transferring waitqueue entries from smc socket->wq to clcsock->wq. The owners of these entries, such as epoll, have no idea that the entries have been transferred to a different socket wait queue and still use original waitqueue spinlock (smc socket->wq.wait.lock) to make the entries operation exclusive, but it doesn't work. The operations to the entries, such as removing from the waitqueue (now is clcsock->wq after fallback), may cause a crash when clcsock waitqueue is being iterated over at the moment.

This patch tries to fix this by no longer transferring wait queue entries privately, but introducing own implementations of clcsock's callback functions in fallback situation. The callback functions will forward the wakeup to smc socket->wq if clcsock->wq is actually woken up and smc socket->wq has remaining entries.(CVE-2022-48721)

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

ice: Do not use WQ_MEM_RECLAIM flag for workqueue

When both ice and the irdma driver are loaded, a warning in check_flush_dependency is being triggered. This is due to ice driver workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one is not.

According to kernel documentation, this flag should be set if the workqueue will be involved in the kernel's memory reclamation flow. Since it is not, there is no need for the ice driver's WQ to have this flag set so remove it.

Example trace:

[ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0 [ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1 0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ +0.000161] [last unloaded: bonding] [ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1 [ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020 [ +0.000003] Workqueue: ice ice_service_task [ice] [ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0 [ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08 9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06 [ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282 [ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000 [ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80 [ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112 [ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000 [ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400 [ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000 [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0 [ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000002] PKRU: 55555554 [ +0.000003] Call Trace: [ +0.000002] <TASK> [ +0.000003] __flush_workqueue+0x203/0x840 [ +0.000006] ? mutex_unlock+0x84/0xd0 [ +0.000008] ? __pfx_mutex_unlock+0x10/0x10 [ +0.000004] ? __pfx___flush_workqueue+0x10/0x10 [ +0.000006] ? mutex_lock+0xa3/0xf0 [ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core] [ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core] [ +0.000094] ib_unregister_device+0x25/0x30 [ib_core] [ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma] [ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma] [ +0.000059] ? up_write+0x5c/0x90 [ +0.000005] irdma_remove+0x36/0x90 [irdma] [ +0.000062] auxiliary_bus_remove+0x32/0x50 [ +0.000007] device_r ---truncated---(CVE-2023-52743)

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

ksmbd: fix slab out of bounds write in smb_inherit_dacl()

slab out-of-bounds write is caused by that offsets is bigger than pntsd allocation size. This patch add the check to validate 3 offsets using allocation size.(CVE-2023-52755)

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

Bluetooth: btusb: Add date->evt_skb is NULL check

fix crash because of null pointers

[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 6104.969667] #PF: supervisor read access in kernel mode [ 6104.969668] #PF: error_code(0x0000) - not-present page [ 6104.969670] PGD 0 P4D 0 [ 6104.969673] Oops: 0000 [#1] SMP NOPTI [ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb] [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246 [ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006 [ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000 [ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001 [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0 [ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90 [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000 [ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0 [ 6104.969701] PKRU: 55555554 [ 6104.969702] Call Trace: [ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb] [ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth] [ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth] [ 6104.969753] rfkill_set_block+0x92/0x160 [ 6104.969755] rfkill_fop_write+0x136/0x1e0 [ 6104.969759] __vfs_write+0x18/0x40 [ 6104.969761] vfs_write+0xdf/0x1c0 [ 6104.969763] ksys_write+0xb1/0xe0 [ 6104.969765] __x64_sys_write+0x1a/0x20 [ 6104.969769] do_syscall_64+0x51/0x180 [ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6104.969773] RIP: 0033:0x7f5a21f18fef [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef [ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012 [ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017 [ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002 [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0(CVE-2023-52833)

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

f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock

It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case.(CVE-2024-34027)

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

null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'

Writing 'power' and 'submit_queues' concurrently will trigger kernel panic:

Test script:

modprobe null_blk nr_devices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submit_queues; echo 4 > submit_queues; done & while true; do echo 1 > power; echo 0 > power; done

Test result:

BUG: kernel NULL pointer dereference, address: 0000000000000148 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:__lock_acquire+0x41d/0x28f0 Call Trace: <TASK> lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive_removal+0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x79/0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150

This is because del_gendisk() can concurrent with blk_mq_update_nr_hw_queues():

nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // still set while gendisk is deleted return 0 blk_mq_update_nr_hw_queues dev->nullb = NULL

Fix this problem by resuing the global mutex to protect nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)

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

bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq

Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0. In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called. roundup_pow_of_two is documented as undefined for 0.

Fix it in the one caller that had this combination.

The undefined behavior was detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re] ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kmalloc+0x1b6/0x4f0 ? create_qp.part.0+0x128/0x1c0 [ib_core] ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re] create_qp.part.0+0x128/0x1c0 [ib_core] ib_create_qp_kernel+0x50/0xd0 [ib_core] create_mad_qp+0x8e/0xe0 [ib_core] ? __pfx_qp_event_handler+0x10/0x10 [ib_core] ib_mad_init_device+0x2be/0x680 [ib_core] add_client_context+0x10d/0x1a0 [ib_core] enable_device_and_get+0xe0/0x1d0 [ib_core] ib_register_device+0x53c/0x630 [ib_core] ? srso_alias_return_thunk+0x5/0xfbef5 bnxt_re_probe+0xbd8/0xe50 [bnxt_re] ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re] auxiliary_bus_probe+0x49/0x80 ? driver_sysfs_add+0x57/0xc0 really_probe+0xde/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8f/0xe0 bus_add_driver+0x146/0x220 driver_register+0x72/0xd0 __auxiliary_driver_register+0x6e/0xd0 ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] bnxt_re_mod_init+0x3e/0xff0 [bnxt_re] ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] do_one_initcall+0x5b/0x310 do_init_module+0x90/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x121/0x2b0 __x64_sys_finit_module+0x5e/0xb0 do_syscall_64+0x82/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode_prepare+0x149/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode+0x75/0x230 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x8e/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? __count_memcg_events+0x69/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events.constprop.0+0x1a/0x30 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1f0/0x300 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x34e/0x640 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60 </TASK> ---[ end trace ]---(CVE-2024-38540)

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

net: openvswitch: fix overwriting ct original tuple for ICMPv6

OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.

OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers.

Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet.

It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.

ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten.

The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace.

ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue.

Initializing the whole thing before parsing is needed because ND packet may not contain all the options.

The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.(CVE-2024-38558)

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

gfs2: Fix potential glock use-after-free on unmount

When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.

To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.

As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.(CVE-2024-38570)

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

r8169: Fix possible ring buffer corruption on fragmented Tx packets.

This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2().

To fix this, postpone inspecting nr_frags until after any padding has been applied.(CVE-2024-38586)

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

md: fix resync softlockup when bitmap size is less than array size

Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup:

kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace: <TASK> md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30

And the detailed process is as follows:

md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never change

Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") return early from md_bitmap_get_counter(), without setting returned blocks.

Fix this problem by always set returned blocks from md_bitmap_get_counter"(), as it used to be.

Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed.(CVE-2024-38598)

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

ALSA: core: Fix NULL module pointer assignment at card init

The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal.

For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in.

Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.(CVE-2024-38605)

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

cpufreq: exit() callback is optional

The exit() callback is optional and shouldn't be called without checking a valid pointer first.

Also, we must clear freq_table pointer even if the exit() callback isn't present.(CVE-2024-38615)

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

vfio/pci: fix potential memory leak in vfio_intx_enable()

If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.(CVE-2024-38632)

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

kdb: Fix buffer overflow during tab-complete

Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer.

Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around.(CVE-2024-39480)

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

bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()

In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read.

BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]---

Fix it by adding a check of string length before using it.(CVE-2024-39487)

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

arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY

When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly.

The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays.

When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:

struct bug_entry {
    signed int      bug_addr_disp;  // 4 bytes
    signed int      file_disp;  // 4 bytes
    unsigned short  line;       // 2 bytes
    unsigned short  flags;      // 2 bytes
}

... with 12 bytes total, requiring 4-byte alignment.

When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:

struct bug_entry {
    signed int      bug_addr_disp;  // 4 bytes
    unsigned short  flags;      // 2 bytes
    &lt; implicit padding &gt;      // 2 bytes
}

... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment.

When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes.

For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries:

for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug)
    if (bugaddr == bug_addr(bug))
        return bug;

However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries:

mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);

... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry:

sechdrs[i].sh_size == 6
sizeof(struct bug_entry) == 8;

sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;

Consequently module_find_bug() will miss the last bug_entry when it does:

for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug)
    if (bugaddr == bug_addr(bug))
        goto out;

... which can lead to a kenrel panic due to an unhandled bug.

This can be demonstrated with the following module:

static int __init buginit(void)
{
    WARN(1, &quot;hello\n&quot;);
    return 0;
}

static void __exit bugexit(void)
{
}

module_init(buginit);
module_exit(bugexit);
MODULE_LICENSE(&quot;GPL&quot;);

... which will trigger a kernel panic when loaded:

------------[ cut here ]------------
hello
Unexpected kernel BRK exception at EL1
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in: hello(O+)
CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8
Hardware name: linux,dummy-virt (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : buginit+0x18/0x1000 [hello]
lr : buginit+0x18/0x1000 [hello]
sp : ffff800080533ae0
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
Call trace:
 buginit+0x18/0x1000 [hello]
 do_one_initcall+0x80/0x1c8
 do_init_module+0x60/0x218
 load_module+0x1ba4/0x1d70
 __do_sys_init_module+0x198/0x1d0
 __arm64_sys_init_module+0x1c/0x28
 invoke_syscall+0x48/0x114
 el0_svc

---truncated---(CVE-2024-39488)

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

ipv6: sr: fix memleak in seg6_hmac_init_algo

seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms.

Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly.(CVE-2024-39489)

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

sock_map: avoid race between sock_map_close and sk_psock_put

sk_psock_get will return NULL if the refcount of psock has gone to 0, which will happen when the last call of sk_psock_put is done. However, sk_psock_drop may not have finished yet, so the close callback will still point to sock_map_close despite psock being NULL.

This can be reproduced with a thread deleting an element from the sock map, while the second one creates a socket, adds it to the map and closes it.

That will trigger the WARN_ON_ONCE:

------------[ cut here ]------------ WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Modules linked in: CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02 RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293 RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000 RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0 RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3 R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840 R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870 FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0 Call Trace: <TASK> unix_release+0x87/0xc0 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c:1556 [inline] __se_sys_close fs/open.c:1541 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb37d618070 Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070 RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>

Use sk_psock, which will only check that the pointer is not been set to NULL yet, which should only happen after the callbacks are restored. If, then, a reference can still be gotten, we may call sk_psock_stop and cancel psock->work.

As suggested by Paolo Abeni, reorder the condition so the control flow is less convoluted.

After that change, the reproducer does not trigger the WARN_ON_ONCE anymore.(CVE-2024-39500)

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

mptcp: ensure snd_una is properly initialized on connect

This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snd_una is still left uninitialized.

Address the issue explicitly initializing snd_una together with snd_nxt and write_seq.(CVE-2024-40931)

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

f2fs: remove clear SB_INLINECRYPT flag in default_options

In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable.

Thread A: Thread B:

-f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag

                                      -fscrypt_select_encryption_impl

-parse_options <- set SB_INLINECRYPT again(CVE-2024-40971)

Severity

7.8 (High)


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

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47391	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48721	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52743	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52755	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52833	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-34027	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36478	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38540	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38558	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38570	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38586	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38598	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38605	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38615	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38632	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39480	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39487	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39488	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39489	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39500	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40931	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40971	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.85.0.166.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.85.0.166.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.85.0.166.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\nRDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests\r\n\r\nThe FSM can run in a circle allowing rdma_resolve_ip() to be called twice\non the same id_priv. While this cannot happen without going through the\nwork, it violates the invariant that the same address resolution\nbackground request cannot be active twice.\r\n\r\n       CPU 1                                  CPU 2\r\n\r\nrdma_resolve_addr():\n  RDMA_CM_IDLE -\u0026gt; RDMA_CM_ADDR_QUERY\n  rdma_resolve_ip(addr_handler)  #1\r\n\r\n\t\t\t process_one_req(): for #1\n                          addr_handler():\n                            RDMA_CM_ADDR_QUERY -\u0026gt; RDMA_CM_ADDR_BOUND\n                            mutex_unlock(\u0026amp;id_priv-\u0026gt;handler_mutex);\n                            [.. handler still running ..]\r\n\r\nrdma_resolve_addr():\n  RDMA_CM_ADDR_BOUND -\u0026gt; RDMA_CM_ADDR_QUERY\n  rdma_resolve_ip(addr_handler)\n    !! two requests are now on the req_list\r\n\r\nrdma_destroy_id():\n destroy_id_handler_unlock():\n  _destroy_id():\n   cma_cancel_operation():\n    rdma_addr_cancel()\r\n\r\n                          // process_one_req() self removes it\n\t\t          spin_lock_bh(\u0026amp;lock);\n                           cancel_delayed_work(\u0026amp;req-\u0026gt;work);\n\t                   if (!list_empty(\u0026amp;req-\u0026gt;list)) == true\r\n\r\n      ! rdma_addr_cancel() returns after process_on_req #1 is done\r\n\r\n   kfree(id_priv)\r\n\r\n\t\t\t process_one_req(): for #2\n                          addr_handler():\n\t                    mutex_lock(\u0026amp;id_priv-\u0026gt;handler_mutex);\n                            !! Use after free on id_priv\r\n\r\nrdma_addr_cancel() expects there to be one req on the list and only\ncancels the first one. The self-removal behavior of the work only happens\nafter the handler has returned. This yields a situations where the\nreq_list can have two reqs for the same \u0026quot;handle\u0026quot; but rdma_addr_cancel()\nonly cancels the first one.\r\n\r\nThe second req remains active beyond rdma_destroy_id() and will\nuse-after-free id_priv once it inevitably triggers.\r\n\r\nFix this by remembering if the id_priv has called rdma_resolve_ip() and\nalways cancel before calling it again. This ensures the req_list never\ngets more than one item in it and doesn\u0026apos;t cost anything in the normal flow\nthat never uses this strange error path.(CVE-2021-47391)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Forward wakeup to smc socket waitqueue after fallback\r\n\r\nWhen we replace TCP with SMC and a fallback occurs, there may be\nsome socket waitqueue entries remaining in smc socket-\u0026gt;wq, such\nas eppoll_entries inserted by userspace applications.\r\n\r\nAfter the fallback, data flows over TCP/IP and only clcsocket-\u0026gt;wq\nwill be woken up. Applications can\u0026apos;t be notified by the entries\nwhich were inserted in smc socket-\u0026gt;wq before fallback. So we need\na mechanism to wake up smc socket-\u0026gt;wq at the same time if some\nentries remaining in it.\r\n\r\nThe current workaround is to transfer the entries from smc socket-\u0026gt;wq\nto clcsock-\u0026gt;wq during the fallback. But this may cause a crash\nlike this:\r\n\r\n general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI\n CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E     5.16.0+ #107\n RIP: 0010:__wake_up_common+0x65/0x170\n Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  __wake_up_common_lock+0x7a/0xc0\n  sock_def_readable+0x3c/0x70\n  tcp_data_queue+0x4a7/0xc40\n  tcp_rcv_established+0x32f/0x660\n  ? sk_filter_trim_cap+0xcb/0x2e0\n  tcp_v4_do_rcv+0x10b/0x260\n  tcp_v4_rcv+0xd2a/0xde0\n  ip_protocol_deliver_rcu+0x3b/0x1d0\n  ip_local_deliver_finish+0x54/0x60\n  ip_local_deliver+0x6a/0x110\n  ? tcp_v4_early_demux+0xa2/0x140\n  ? tcp_v4_early_demux+0x10d/0x140\n  ip_sublist_rcv_finish+0x49/0x60\n  ip_sublist_rcv+0x19d/0x230\n  ip_list_rcv+0x13e/0x170\n  __netif_receive_skb_list_core+0x1c2/0x240\n  netif_receive_skb_list_internal+0x1e6/0x320\n  napi_complete_done+0x11d/0x190\n  mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]\n  __napi_poll+0x3c/0x1b0\n  net_rx_action+0x27c/0x300\n  __do_softirq+0x114/0x2d2\n  irq_exit_rcu+0xb4/0xe0\n  common_interrupt+0xba/0xe0\n  \u0026lt;/IRQ\u0026gt;\n  \u0026lt;TASK\u0026gt;\r\n\r\nThe crash is caused by privately transferring waitqueue entries from\nsmc socket-\u0026gt;wq to clcsock-\u0026gt;wq. The owners of these entries, such as\nepoll, have no idea that the entries have been transferred to a\ndifferent socket wait queue and still use original waitqueue spinlock\n(smc socket-\u0026gt;wq.wait.lock) to make the entries operation exclusive,\nbut it doesn\u0026apos;t work. The operations to the entries, such as removing\nfrom the waitqueue (now is clcsock-\u0026gt;wq after fallback), may cause a\ncrash when clcsock waitqueue is being iterated over at the moment.\r\n\r\nThis patch tries to fix this by no longer transferring wait queue\nentries privately, but introducing own implementations of clcsock\u0026apos;s\ncallback functions in fallback situation. The callback functions will\nforward the wakeup to smc socket-\u0026gt;wq if clcsock-\u0026gt;wq is actually woken\nup and smc socket-\u0026gt;wq has remaining entries.(CVE-2022-48721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Do not use WQ_MEM_RECLAIM flag for workqueue\r\n\r\nWhen both ice and the irdma driver are loaded, a warning in\ncheck_flush_dependency is being triggered. This is due to ice driver\nworkqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one\nis not.\r\n\r\nAccording to kernel documentation, this flag should be set if the\nworkqueue will be involved in the kernel\u0026apos;s memory reclamation flow.\nSince it is not, there is no need for the ice driver\u0026apos;s WQ to have this\nflag set so remove it.\r\n\r\nExample trace:\r\n\r\n[  +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0\n[  +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0\n[  +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha\nin_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel\n_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1\n0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_\ncore_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs\nib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter\nacpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba\nta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse\n[  +0.000161]  [last unloaded: bonding]\n[  +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S                 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1\n[  +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020\n[  +0.000003] Workqueue: ice ice_service_task [ice]\n[  +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0\n[  +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08\n9f e8 bb d3 07 01 \u0026lt;0f\u0026gt; 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06\n[  +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282\n[  +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000\n[  +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80\n[  +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112\n[  +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000\n[  +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400\n[  +0.000004] FS:  0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000\n[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0\n[  +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  +0.000002] PKRU: 55555554\n[  +0.000003] Call Trace:\n[  +0.000002]  \u0026lt;TASK\u0026gt;\n[  +0.000003]  __flush_workqueue+0x203/0x840\n[  +0.000006]  ? mutex_unlock+0x84/0xd0\n[  +0.000008]  ? __pfx_mutex_unlock+0x10/0x10\n[  +0.000004]  ? __pfx___flush_workqueue+0x10/0x10\n[  +0.000006]  ? mutex_lock+0xa3/0xf0\n[  +0.000005]  ib_cache_cleanup_one+0x39/0x190 [ib_core]\n[  +0.000174]  __ib_unregister_device+0x84/0xf0 [ib_core]\n[  +0.000094]  ib_unregister_device+0x25/0x30 [ib_core]\n[  +0.000093]  irdma_ib_unregister_device+0x97/0xc0 [irdma]\n[  +0.000064]  ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]\n[  +0.000059]  ? up_write+0x5c/0x90\n[  +0.000005]  irdma_remove+0x36/0x90 [irdma]\n[  +0.000062]  auxiliary_bus_remove+0x32/0x50\n[  +0.000007]  device_r\n---truncated---(CVE-2023-52743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix slab out of bounds write in smb_inherit_dacl()\r\n\r\nslab out-of-bounds write is caused by that offsets is bigger than pntsd\nallocation size. This patch add the check to validate 3 offsets using\nallocation size.(CVE-2023-52755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: btusb: Add date-\u0026gt;evt_skb is NULL check\r\n\r\nfix crash because of null pointers\r\n\r\n[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8\n[ 6104.969667] #PF: supervisor read access in kernel mode\n[ 6104.969668] #PF: error_code(0x0000) - not-present page\n[ 6104.969670] PGD 0 P4D 0\n[ 6104.969673] Oops: 0000 [#1] SMP NOPTI\n[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]\n[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246\n[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006\n[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000\n[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001\n[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0\n[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90\n[ 6104.969697] FS:  00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000\n[ 6104.969699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0\n[ 6104.969701] PKRU: 55555554\n[ 6104.969702] Call Trace:\n[ 6104.969708]  btusb_mtk_shutdown+0x44/0x80 [btusb]\n[ 6104.969732]  hci_dev_do_close+0x470/0x5c0 [bluetooth]\n[ 6104.969748]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]\n[ 6104.969753]  rfkill_set_block+0x92/0x160\n[ 6104.969755]  rfkill_fop_write+0x136/0x1e0\n[ 6104.969759]  __vfs_write+0x18/0x40\n[ 6104.969761]  vfs_write+0xdf/0x1c0\n[ 6104.969763]  ksys_write+0xb1/0xe0\n[ 6104.969765]  __x64_sys_write+0x1a/0x20\n[ 6104.969769]  do_syscall_64+0x51/0x180\n[ 6104.969771]  entry_SYSCALL_64_after_hwframe+0x44/0xa9\n[ 6104.969773] RIP: 0033:0x7f5a21f18fef\n[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\n[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef\n[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012\n[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017\n[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002\n[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0(CVE-2023-52833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock\r\n\r\nIt needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock\nto avoid racing with checkpoint, otherwise, filesystem metadata including\nblkaddr in dnode, inode fields and .total_valid_block_count may be\ncorrupted after SPO case.(CVE-2024-34027)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnull_blk: fix null-ptr-dereference while configuring \u0026apos;power\u0026apos; and \u0026apos;submit_queues\u0026apos;\r\n\r\nWriting \u0026apos;power\u0026apos; and \u0026apos;submit_queues\u0026apos; concurrently will trigger kernel\npanic:\r\n\r\nTest script:\r\n\r\nmodprobe null_blk nr_devices=0\nmkdir -p /sys/kernel/config/nullb/nullb0\nwhile true; do echo 1 \u0026gt; submit_queues; echo 4 \u0026gt; submit_queues; done \u0026amp;\nwhile true; do echo 1 \u0026gt; power; echo 0 \u0026gt; power; done\r\n\r\nTest result:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000148\nOops: 0000 [#1] PREEMPT SMP\nRIP: 0010:__lock_acquire+0x41d/0x28f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n lock_acquire+0x121/0x450\n down_write+0x5f/0x1d0\n simple_recursive_removal+0x12f/0x5c0\n blk_mq_debugfs_unregister_hctxs+0x7c/0x100\n blk_mq_update_nr_hw_queues+0x4a3/0x720\n nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]\n nullb_device_submit_queues_store+0x79/0xf0 [null_blk]\n configfs_write_iter+0x119/0x1e0\n vfs_write+0x326/0x730\n ksys_write+0x74/0x150\r\n\r\nThis is because del_gendisk() can concurrent with\nblk_mq_update_nr_hw_queues():\r\n\r\nnullb_device_power_store\tnullb_apply_submit_queues\n null_del_dev\n del_gendisk\n\t\t\t\t nullb_update_nr_hw_queues\n\t\t\t\t  if (!dev-\u0026gt;nullb)\n\t\t\t\t  // still set while gendisk is deleted\n\t\t\t\t   return 0\n\t\t\t\t  blk_mq_update_nr_hw_queues\n dev-\u0026gt;nullb = NULL\r\n\r\nFix this problem by resuing the global mutex to protect\nnullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq\r\n\r\nUndefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called\nwith hwq_attr-\u0026gt;aux_depth != 0 and hwq_attr-\u0026gt;aux_stride == 0.\nIn that case, \u0026quot;roundup_pow_of_two(hwq_attr-\u0026gt;aux_stride)\u0026quot; gets called.\nroundup_pow_of_two is documented as undefined for 0.\r\n\r\nFix it in the one caller that had this combination.\r\n\r\nThe undefined behavior was detected by UBSAN:\n  UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13\n  shift exponent 64 is too large for 64-bit type \u0026apos;long unsigned int\u0026apos;\n  CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4\n  Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x5d/0x80\n   ubsan_epilogue+0x5/0x30\n   __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec\n   __roundup_pow_of_two+0x25/0x35 [bnxt_re]\n   bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]\n   bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]\n   bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? __kmalloc+0x1b6/0x4f0\n   ? create_qp.part.0+0x128/0x1c0 [ib_core]\n   ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]\n   create_qp.part.0+0x128/0x1c0 [ib_core]\n   ib_create_qp_kernel+0x50/0xd0 [ib_core]\n   create_mad_qp+0x8e/0xe0 [ib_core]\n   ? __pfx_qp_event_handler+0x10/0x10 [ib_core]\n   ib_mad_init_device+0x2be/0x680 [ib_core]\n   add_client_context+0x10d/0x1a0 [ib_core]\n   enable_device_and_get+0xe0/0x1d0 [ib_core]\n   ib_register_device+0x53c/0x630 [ib_core]\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   bnxt_re_probe+0xbd8/0xe50 [bnxt_re]\n   ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]\n   auxiliary_bus_probe+0x49/0x80\n   ? driver_sysfs_add+0x57/0xc0\n   really_probe+0xde/0x340\n   ? pm_runtime_barrier+0x54/0x90\n   ? __pfx___driver_attach+0x10/0x10\n   __driver_probe_device+0x78/0x110\n   driver_probe_device+0x1f/0xa0\n   __driver_attach+0xba/0x1c0\n   bus_for_each_dev+0x8f/0xe0\n   bus_add_driver+0x146/0x220\n   driver_register+0x72/0xd0\n   __auxiliary_driver_register+0x6e/0xd0\n   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n   bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]\n   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n   do_one_initcall+0x5b/0x310\n   do_init_module+0x90/0x250\n   init_module_from_file+0x86/0xc0\n   idempotent_init_module+0x121/0x2b0\n   __x64_sys_finit_module+0x5e/0xb0\n   do_syscall_64+0x82/0x160\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? syscall_exit_to_user_mode_prepare+0x149/0x170\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? syscall_exit_to_user_mode+0x75/0x230\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? do_syscall_64+0x8e/0x160\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? __count_memcg_events+0x69/0x100\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? count_memcg_events.constprop.0+0x1a/0x30\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? handle_mm_fault+0x1f0/0x300\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? do_user_addr_fault+0x34e/0x640\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  RIP: 0033:0x7f4e5132821d\n  Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48\n  RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139\n  RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d\n  RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b\n  RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0\n  R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d\n  R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace ]---(CVE-2024-38540)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: openvswitch: fix overwriting ct original tuple for ICMPv6\r\n\r\nOVS_PACKET_CMD_EXECUTE has 3 main attributes:\n - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.\n - OVS_PACKET_ATTR_PACKET - Binary packet content.\n - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.\r\n\r\nOVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure\nwith the metadata like conntrack state, input port, recirculation id,\netc.  Then the packet itself gets parsed to populate the rest of the\nkeys from the packet headers.\r\n\r\nWhenever the packet parsing code starts parsing the ICMPv6 header, it\nfirst zeroes out fields in the key corresponding to Neighbor Discovery\ninformation even if it is not an ND packet.\r\n\r\nIt is an \u0026apos;ipv6.nd\u0026apos; field.  However, the \u0026apos;ipv6\u0026apos; is a union that shares\nthe space between \u0026apos;nd\u0026apos; and \u0026apos;ct_orig\u0026apos; that holds the original tuple\nconntrack metadata parsed from the OVS_PACKET_ATTR_KEY.\r\n\r\nND packets should not normally have conntrack state, so it\u0026apos;s fine to\nshare the space, but normal ICMPv6 Echo packets or maybe other types of\nICMPv6 can have the state attached and it should not be overwritten.\r\n\r\nThe issue results in all but the last 4 bytes of the destination\naddress being wiped from the original conntrack tuple leading to\nincorrect packet matching and potentially executing wrong actions\nin case this packet recirculates within the datapath or goes back\nto userspace.\r\n\r\nND fields should not be accessed in non-ND packets, so not clearing\nthem should be fine.  Executing memset() only for actual ND packets to\navoid the issue.\r\n\r\nInitializing the whole thing before parsing is needed because ND packet\nmay not contain all the options.\r\n\r\nThe issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn\u0026apos;t\naffect packets entering OVS datapath from network interfaces, because\nin this case CT metadata is populated from skb after the packet is\nalready parsed.(CVE-2024-38558)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: Fix potential glock use-after-free on unmount\r\n\r\nWhen a DLM lockspace is released and there ares still locks in that\nlockspace, DLM will unlock those locks automatically.  Commit\nfb6791d100d1b started exploiting this behavior to speed up filesystem\nunmount: gfs2 would simply free glocks it didn\u0026apos;t want to unlock and then\nrelease the lockspace.  This didn\u0026apos;t take the bast callbacks for\nasynchronous lock contention notifications into account, which remain\nactive until until a lock is unlocked or its lockspace is released.\r\n\r\nTo prevent those callbacks from accessing deallocated objects, put the\nglocks that should not be unlocked on the sd_dead_glocks list, release\nthe lockspace, and only then free those glocks.\r\n\r\nAs an additional measure, ignore unexpected ast and bast callbacks if\nthe receiving glock is dead.(CVE-2024-38570)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\r\n\r\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\r\n\r\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\r\n\r\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied.(CVE-2024-38586)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix resync softlockup when bitmap size is less than array size\r\n\r\nIs is reported that for dm-raid10, lvextend + lvchange --syncaction will\ntrigger following softlockup:\r\n\r\nkernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]\nCPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1\nRIP: 0010:_raw_spin_unlock_irq+0x13/0x30\nCall Trace:\n \u0026lt;TASK\u0026gt;\n md_bitmap_start_sync+0x6b/0xf0\n raid10_sync_request+0x25c/0x1b40 [raid10]\n md_do_sync+0x64b/0x1020\n md_thread+0xa7/0x170\n kthread+0xcf/0x100\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1a/0x30\r\n\r\nAnd the detailed process is as follows:\r\n\r\nmd_do_sync\n j = mddev-\u0026gt;resync_min\n while (j \u0026lt; max_sectors)\n  sectors = raid10_sync_request(mddev, j, \u0026amp;skipped)\n   if (!md_bitmap_start_sync(..., \u0026amp;sync_blocks))\n    // md_bitmap_start_sync set sync_blocks to 0\n    return sync_blocks + sectors_skippe;\n  // sectors = 0;\n  j += sectors;\n  // j never change\r\n\r\nRoot cause is that commit 301867b1c168 (\u0026quot;md/raid10: check\nslab-out-of-bounds in md_bitmap_get_counter\u0026quot;) return early from\nmd_bitmap_get_counter(), without setting returned blocks.\r\n\r\nFix this problem by always set returned blocks from\nmd_bitmap_get_counter\u0026quot;(), as it used to be.\r\n\r\nNoted that this patch just fix the softlockup problem in kernel, the\ncase that bitmap size doesn\u0026apos;t match array size still need to be fixed.(CVE-2024-38598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: core: Fix NULL module pointer assignment at card init\r\n\r\nThe commit 81033c6b584b (\u0026quot;ALSA: core: Warn on empty module\u0026quot;)\nintroduced a WARN_ON() for a NULL module pointer passed at snd_card\nobject creation, and it also wraps the code around it with \u0026apos;#ifdef\nMODULE\u0026apos;.  This works in most cases, but the devils are always in\ndetails.  \u0026quot;MODULE\u0026quot; is defined when the target code (i.e. the sound\ncore) is built as a module; but this doesn\u0026apos;t mean that the caller is\nalso built-in or not.  Namely, when only the sound core is built-in\n(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),\nthe passed module pointer is ignored even if it\u0026apos;s non-NULL, and\ncard-\u0026gt;module remains as NULL.  This would result in the missing module\nreference up/down at the device open/close, leading to a race with the\ncode execution after the module removal.\r\n\r\nFor addressing the bug, move the assignment of card-\u0026gt;module again out\nof ifdef.  The WARN_ON() is still wrapped with ifdef because the\nmodule can be really NULL when all sound drivers are built-in.\r\n\r\nNote that we keep \u0026apos;ifdef MODULE\u0026apos; for WARN_ON(), otherwise it would\nlead to a false-positive NULL module check.  Admittedly it won\u0026apos;t catch\nperfectly, i.e. no check is performed when CONFIG_SND=y.  But, it\u0026apos;s no\nreal problem as it\u0026apos;s only for debugging, and the condition is pretty\nrare.(CVE-2024-38605)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpufreq: exit() callback is optional\r\n\r\nThe exit() callback is optional and shouldn\u0026apos;t be called without checking\na valid pointer first.\r\n\r\nAlso, we must clear freq_table pointer even if the exit() callback isn\u0026apos;t\npresent.(CVE-2024-38615)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: fix potential memory leak in vfio_intx_enable()\r\n\r\nIf vfio_irq_ctx_alloc() failed will lead to \u0026apos;name\u0026apos; memory leak.(CVE-2024-38632)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkdb: Fix buffer overflow during tab-complete\r\n\r\nCurrently, when the user attempts symbol completion with the Tab key, kdb\nwill use strncpy() to insert the completed symbol into the command buffer.\nUnfortunately it passes the size of the source buffer rather than the\ndestination to strncpy() with predictably horrible results. Most obviously\nif the command buffer is already full but cp, the cursor position, is in\nthe middle of the buffer, then we will write past the end of the supplied\nbuffer.\r\n\r\nFix this by replacing the dubious strncpy() calls with memmove()/memcpy()\ncalls plus explicit boundary checks to make sure we have enough space\nbefore we start moving characters around.(CVE-2024-39480)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()\r\n\r\nIn function bond_option_arp_ip_targets_set(), if newval-\u0026gt;string is an\nempty string, newval-\u0026gt;string+1 will point to the byte after the\nstring, causing an out-of-bound read.\r\n\r\nBUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418\nRead of size 1 at addr ffff8881119c4781 by task syz-executor665/8107\nCPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:364 [inline]\n print_report+0xc1/0x5e0 mm/kasan/report.c:475\n kasan_report+0xbe/0xf0 mm/kasan/report.c:588\n strlen+0x7d/0xa0 lib/string.c:418\n __fortify_strlen include/linux/fortify-string.h:210 [inline]\n in4_pton+0xa3/0x3f0 net/core/utils.c:130\n bond_option_arp_ip_targets_set+0xc2/0x910\ndrivers/net/bonding/bond_options.c:1201\n __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767\n __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792\n bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817\n bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156\n dev_attr_store+0x54/0x80 drivers/base/core.c:2366\n sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136\n kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x96a/0xd80 fs/read_write.c:584\n ksys_write+0x122/0x250 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n---[ end trace ]---\r\n\r\nFix it by adding a check of string length before using it.(CVE-2024-39487)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY\r\n\r\nWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes\nto bug_table entries, and as a result the last entry in a bug table will\nbe ignored, potentially leading to an unexpected panic(). All prior\nentries in the table will be handled correctly.\r\n\r\nThe arm64 ABI requires that struct fields of up to 8 bytes are\nnaturally-aligned, with padding added within a struct such that struct\nare suitably aligned within arrays.\r\n\r\nWhen CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:\r\n\r\n\tstruct bug_entry {\n\t\tsigned int      bug_addr_disp;\t// 4 bytes\n\t\tsigned int      file_disp;\t// 4 bytes\n\t\tunsigned short  line;\t\t// 2 bytes\n\t\tunsigned short  flags;\t\t// 2 bytes\n\t}\r\n\r\n... with 12 bytes total, requiring 4-byte alignment.\r\n\r\nWhen CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:\r\n\r\n\tstruct bug_entry {\n\t\tsigned int      bug_addr_disp;\t// 4 bytes\n\t\tunsigned short  flags;\t\t// 2 bytes\n\t\t\u0026lt; implicit padding \u0026gt;\t\t// 2 bytes\n\t}\r\n\r\n... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing\npadding, requiring 4-byte alginment.\r\n\r\nWhen we create a bug_entry in assembly, we align the start of the entry\nto 4 bytes, which implicitly handles padding for any prior entries.\nHowever, we do not align the end of the entry, and so when\nCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding\nbytes.\r\n\r\nFor the main kernel image this is not a problem as find_bug() doesn\u0026apos;t\ndepend on the trailing padding bytes when searching for entries:\r\n\r\n\tfor (bug = __start___bug_table; bug \u0026lt; __stop___bug_table; ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\treturn bug;\r\n\r\nHowever for modules, module_bug_finalize() depends on the trailing\nbytes when calculating the number of entries:\r\n\r\n\tmod-\u0026gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);\r\n\r\n... and as the last bug_entry lacks the necessary padding bytes, this entry\nwill not be counted, e.g. in the case of a single entry:\r\n\r\n\tsechdrs[i].sh_size == 6\n\tsizeof(struct bug_entry) == 8;\r\n\r\n\tsechdrs[i].sh_size / sizeof(struct bug_entry) == 0;\r\n\r\nConsequently module_find_bug() will miss the last bug_entry when it does:\r\n\r\n\tfor (i = 0; i \u0026lt; mod-\u0026gt;num_bugs; ++i, ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\tgoto out;\r\n\r\n... which can lead to a kenrel panic due to an unhandled bug.\r\n\r\nThis can be demonstrated with the following module:\r\n\r\n\tstatic int __init buginit(void)\n\t{\n\t\tWARN(1, \u0026quot;hello\\n\u0026quot;);\n\t\treturn 0;\n\t}\r\n\r\n\tstatic void __exit bugexit(void)\n\t{\n\t}\r\n\r\n\tmodule_init(buginit);\n\tmodule_exit(bugexit);\n\tMODULE_LICENSE(\u0026quot;GPL\u0026quot;);\r\n\r\n... which will trigger a kernel panic when loaded:\r\n\r\n\t------------[ cut here ]------------\n\thello\n\tUnexpected kernel BRK exception at EL1\n\tInternal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP\n\tModules linked in: hello(O+)\n\tCPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8\n\tHardware name: linux,dummy-virt (DT)\n\tpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n\tpc : buginit+0x18/0x1000 [hello]\n\tlr : buginit+0x18/0x1000 [hello]\n\tsp : ffff800080533ae0\n\tx29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000\n\tx26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58\n\tx23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0\n\tx20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006\n\tx17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720\n\tx14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312\n\tx11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8\n\tx8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000\n\tx5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000\n\tx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0\n\tCall trace:\n\t buginit+0x18/0x1000 [hello]\n\t do_one_initcall+0x80/0x1c8\n\t do_init_module+0x60/0x218\n\t load_module+0x1ba4/0x1d70\n\t __do_sys_init_module+0x198/0x1d0\n\t __arm64_sys_init_module+0x1c/0x28\n\t invoke_syscall+0x48/0x114\n\t el0_svc\n---truncated---(CVE-2024-39488)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix memleak in seg6_hmac_init_algo\r\n\r\nseg6_hmac_init_algo returns without cleaning up the previous allocations\nif one fails, so it\u0026apos;s going to leak all that memory and the crypto tfms.\r\n\r\nUpdate seg6_hmac_exit to only free the memory when allocated, so we can\nreuse the code directly.(CVE-2024-39489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsock_map: avoid race between sock_map_close and sk_psock_put\r\n\r\nsk_psock_get will return NULL if the refcount of psock has gone to 0, which\nwill happen when the last call of sk_psock_put is done. However,\nsk_psock_drop may not have finished yet, so the close callback will still\npoint to sock_map_close despite psock being NULL.\r\n\r\nThis can be reproduced with a thread deleting an element from the sock map,\nwhile the second one creates a socket, adds it to the map and closes it.\r\n\r\nThat will trigger the WARN_ON_ONCE:\r\n\r\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nModules linked in:\nCPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nCode: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 \u0026lt;0f\u0026gt; 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02\nRSP: 0018:ffffc9000441fda8 EFLAGS: 00010293\nRAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000\nRDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0\nRBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3\nR10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840\nR13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870\nFS:  000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n unix_release+0x87/0xc0 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0xbe/0x240 net/socket.c:1421\n __fput+0x42b/0x8a0 fs/file_table.c:422\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close fs/open.c:1541 [inline]\n __x64_sys_close+0x7f/0x110 fs/open.c:1541\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fb37d618070\nCode: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c\nRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003\nRAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070\nRDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\r\n\r\nUse sk_psock, which will only check that the pointer is not been set to\nNULL yet, which should only happen after the callbacks are restored. If,\nthen, a reference can still be gotten, we may call sk_psock_stop and cancel\npsock-\u0026gt;work.\r\n\r\nAs suggested by Paolo Abeni, reorder the condition so the control flow is\nless convoluted.\r\n\r\nAfter that change, the reproducer does not trigger the WARN_ON_ONCE\nanymore.(CVE-2024-39500)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: ensure snd_una is properly initialized on connect\r\n\r\nThis is strictly related to commit fb7a0d334894 (\u0026quot;mptcp: ensure snd_nxt\nis properly initialized on connect\u0026quot;). It turns out that syzkaller can\ntrigger the retransmit after fallback and before processing any other\nincoming packet - so that snd_una is still left uninitialized.\r\n\r\nAddress the issue explicitly initializing snd_una together with snd_nxt\nand write_seq.(CVE-2024-40931)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: remove clear SB_INLINECRYPT flag in default_options\r\n\r\nIn f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.\nIf create new file or open file during this gap, these files\nwill not use inlinecrypt. Worse case, it may lead to data\ncorruption if wrappedkey_v0 is enable.\r\n\r\nThread A:                               Thread B:\r\n\r\n-f2fs_remount\t\t\t\t-f2fs_file_open or f2fs_new_inode\n  -default_options\n\t\u0026lt;- clear SB_INLINECRYPT flag\r\n\r\n                                          -fscrypt_select_encryption_impl\r\n\r\n  -parse_options\n\t\u0026lt;- set SB_INLINECRYPT again(CVE-2024-40971)",
  "id": "OESA-2024-1860",
  "modified": "2026-08-06T11:07:19Z",
  "published": "2024-07-19T11:07:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47391"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48721"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52743"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34027"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36478"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38540"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38558"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38570"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38586"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38598"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38605"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38615"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38632"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39480"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39487"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39488"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39489"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39500"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40931"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40971"
    }
  ],
  "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-47391",
    "CVE-2022-48721",
    "CVE-2023-52743",
    "CVE-2023-52755",
    "CVE-2023-52833",
    "CVE-2024-34027",
    "CVE-2024-36478",
    "CVE-2024-38540",
    "CVE-2024-38558",
    "CVE-2024-38570",
    "CVE-2024-38586",
    "CVE-2024-38598",
    "CVE-2024-38605",
    "CVE-2024-38615",
    "CVE-2024-38632",
    "CVE-2024-39480",
    "CVE-2024-39487",
    "CVE-2024-39488",
    "CVE-2024-39489",
    "CVE-2024-39500",
    "CVE-2024-40931",
    "CVE-2024-40971"
  ]
}

OESA-2024-1861 (CVE-2023-52755)

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

ksmbd: fix slab out of bounds write in smb_inherit_dacl()

slab out-of-bounds write is caused by that offsets is bigger than pntsd allocation size. This patch add the check to validate 3 offsets using allocation size.(CVE-2023-52755)

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

f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock

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

null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'

Writing 'power' and 'submit_queues' concurrently will trigger kernel panic:

Test script:

modprobe null_blk nr_devices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submit_queues; echo 4 > submit_queues; done & while true; do echo 1 > power; echo 0 > power; done

Test result:

This is because del_gendisk() can concurrent with blk_mq_update_nr_hw_queues():

Fix this problem by resuing the global mutex to protect nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)

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

bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq

Fix it in the one caller that had this combination.

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

net: openvswitch: fix overwriting ct original tuple for ICMPv6

Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet.

It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.

ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue.

Initializing the whole thing before parsing is needed because ND packet may not contain all the options.

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

gfs2: Fix potential glock use-after-free on unmount

To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.

As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.(CVE-2024-38570)

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

r8169: Fix possible ring buffer corruption on fragmented Tx packets.

This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2().

To fix this, postpone inspecting nr_frags until after any padding has been applied.(CVE-2024-38586)

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

ALSA: core: Fix NULL module pointer assignment at card init

For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in.

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

vfio/pci: fix potential memory leak in vfio_intx_enable()

If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.(CVE-2024-38632)

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

kdb: Fix buffer overflow during tab-complete

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

bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()

In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read.

Fix it by adding a check of string length before using it.(CVE-2024-39487)

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

arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY

The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays.

When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:

struct bug_entry {
    signed int      bug_addr_disp;  // 4 bytes
    signed int      file_disp;  // 4 bytes
    unsigned short  line;       // 2 bytes
    unsigned short  flags;      // 2 bytes
}

... with 12 bytes total, requiring 4-byte alignment.

When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:

struct bug_entry {
    signed int      bug_addr_disp;  // 4 bytes
    unsigned short  flags;      // 2 bytes
    &lt; implicit padding &gt;      // 2 bytes
}

... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment.

For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries:

for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug)
    if (bugaddr == bug_addr(bug))
        return bug;

However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries:

mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);

... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry:

sechdrs[i].sh_size == 6
sizeof(struct bug_entry) == 8;

sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;

Consequently module_find_bug() will miss the last bug_entry when it does:

for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug)
    if (bugaddr == bug_addr(bug))
        goto out;

... which can lead to a kenrel panic due to an unhandled bug.

This can be demonstrated with the following module:

static int __init buginit(void)
{
    WARN(1, &quot;hello\n&quot;);
    return 0;
}

static void __exit bugexit(void)
{
}

module_init(buginit);
module_exit(bugexit);
MODULE_LICENSE(&quot;GPL&quot;);

... which will trigger a kernel panic when loaded:

------------[ cut here ]------------
hello
Unexpected kernel BRK exception at EL1
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in: hello(O+)
CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8
Hardware name: linux,dummy-virt (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : buginit+0x18/0x1000 [hello]
lr : buginit+0x18/0x1000 [hello]
sp : ffff800080533ae0
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
Call trace:
 buginit+0x18/0x1000 [hello]
 do_one_initcall+0x80/0x1c8
 do_init_module+0x60/0x218
 load_module+0x1ba4/0x1d70
 __do_sys_init_module+0x198/0x1d0
 __arm64_sys_init_module+0x1c/0x28
 invoke_syscall+0x48/0x114
 el0_svc

---truncated---(CVE-2024-39488)

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

ipv6: sr: fix memleak in seg6_hmac_init_algo

seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms.

Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly.(CVE-2024-39489)

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

sock_map: avoid race between sock_map_close and sk_psock_put

This can be reproduced with a thread deleting an element from the sock map, while the second one creates a socket, adds it to the map and closes it.

That will trigger the WARN_ON_ONCE:

As suggested by Paolo Abeni, reorder the condition so the control flow is less convoluted.

After that change, the reproducer does not trigger the WARN_ON_ONCE anymore.(CVE-2024-39500)

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

ionic: fix use after netif_napi_del()

When queues are started, netif_napi_add() and napi_enable() are called. If there are 4 queues and only 3 queues are used for the current configuration, only 3 queues' napi should be registered and enabled. The ionic_qcq_enable() checks whether the .poll pointer is not NULL for enabling only the using queue' napi. Unused queues' napi will not be registered by netif_napi_add(), so the .poll pointer indicates NULL. But it couldn't distinguish whether the napi was unregistered or not because netif_napi_del() doesn't reset the .poll pointer to NULL. So, ionic_qcq_enable() calls napi_enable() for the queue, which was unregistered by netif_napi_del().

Reproducer: ethtool -L <interface name> rx 1 tx 1 combined 0 ethtool -L <interface name> rx 0 tx 0 combined 1 ethtool -L <interface name> rx 0 tx 0 combined 4

Splat looks like: kernel BUG at net/core/dev.c:6666! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16 Workqueue: events ionic_lif_deferred_work [ionic] RIP: 0010:napi_enable+0x3b/0x40 Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? die+0x33/0x90 ? do_trap+0xd9/0x100 ? napi_enable+0x3b/0x40 ? do_error_trap+0x83/0xb0 ? napi_enable+0x3b/0x40 ? napi_enable+0x3b/0x40 ? exc_invalid_op+0x4e/0x70 ? napi_enable+0x3b/0x40 ? asm_exc_invalid_op+0x16/0x20 ? napi_enable+0x3b/0x40 ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] process_one_work+0x145/0x360 worker_thread+0x2bb/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30(CVE-2024-39502)

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

mptcp: ensure snd_una is properly initialized on connect

Address the issue explicitly initializing snd_una together with snd_nxt and write_seq.(CVE-2024-40931)

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

HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()

Fix a memory leak on logi_dj_recv_send_report() error path.(CVE-2024-40934)

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

f2fs: remove clear SB_INLINECRYPT flag in default_options

Thread A: Thread B:

-f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag

                                      -fscrypt_select_encryption_impl

-parse_options <- set SB_INLINECRYPT again(CVE-2024-40971)

Severity

7.8 (High)


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

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52755	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-34027	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36478	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38540	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38558	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38570	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38586	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38605	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38632	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39480	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39487	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39488	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39489	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39500	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39502	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40931	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40934	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40971	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-219.0.0.122.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-219.0.0.122.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-219.0.0.122.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-219.0.0.122.oe2203sp3"
            }
          ],
          "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\nksmbd: fix slab out of bounds write in smb_inherit_dacl()\r\n\r\nslab out-of-bounds write is caused by that offsets is bigger than pntsd\nallocation size. This patch add the check to validate 3 offsets using\nallocation size.(CVE-2023-52755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock\r\n\r\nIt needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock\nto avoid racing with checkpoint, otherwise, filesystem metadata including\nblkaddr in dnode, inode fields and .total_valid_block_count may be\ncorrupted after SPO case.(CVE-2024-34027)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnull_blk: fix null-ptr-dereference while configuring \u0026apos;power\u0026apos; and \u0026apos;submit_queues\u0026apos;\r\n\r\nWriting \u0026apos;power\u0026apos; and \u0026apos;submit_queues\u0026apos; concurrently will trigger kernel\npanic:\r\n\r\nTest script:\r\n\r\nmodprobe null_blk nr_devices=0\nmkdir -p /sys/kernel/config/nullb/nullb0\nwhile true; do echo 1 \u0026gt; submit_queues; echo 4 \u0026gt; submit_queues; done \u0026amp;\nwhile true; do echo 1 \u0026gt; power; echo 0 \u0026gt; power; done\r\n\r\nTest result:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000148\nOops: 0000 [#1] PREEMPT SMP\nRIP: 0010:__lock_acquire+0x41d/0x28f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n lock_acquire+0x121/0x450\n down_write+0x5f/0x1d0\n simple_recursive_removal+0x12f/0x5c0\n blk_mq_debugfs_unregister_hctxs+0x7c/0x100\n blk_mq_update_nr_hw_queues+0x4a3/0x720\n nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]\n nullb_device_submit_queues_store+0x79/0xf0 [null_blk]\n configfs_write_iter+0x119/0x1e0\n vfs_write+0x326/0x730\n ksys_write+0x74/0x150\r\n\r\nThis is because del_gendisk() can concurrent with\nblk_mq_update_nr_hw_queues():\r\n\r\nnullb_device_power_store\tnullb_apply_submit_queues\n null_del_dev\n del_gendisk\n\t\t\t\t nullb_update_nr_hw_queues\n\t\t\t\t  if (!dev-\u0026gt;nullb)\n\t\t\t\t  // still set while gendisk is deleted\n\t\t\t\t   return 0\n\t\t\t\t  blk_mq_update_nr_hw_queues\n dev-\u0026gt;nullb = NULL\r\n\r\nFix this problem by resuing the global mutex to protect\nnullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq\r\n\r\nUndefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called\nwith hwq_attr-\u0026gt;aux_depth != 0 and hwq_attr-\u0026gt;aux_stride == 0.\nIn that case, \u0026quot;roundup_pow_of_two(hwq_attr-\u0026gt;aux_stride)\u0026quot; gets called.\nroundup_pow_of_two is documented as undefined for 0.\r\n\r\nFix it in the one caller that had this combination.\r\n\r\nThe undefined behavior was detected by UBSAN:\n  UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13\n  shift exponent 64 is too large for 64-bit type \u0026apos;long unsigned int\u0026apos;\n  CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4\n  Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x5d/0x80\n   ubsan_epilogue+0x5/0x30\n   __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec\n   __roundup_pow_of_two+0x25/0x35 [bnxt_re]\n   bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]\n   bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]\n   bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? __kmalloc+0x1b6/0x4f0\n   ? create_qp.part.0+0x128/0x1c0 [ib_core]\n   ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]\n   create_qp.part.0+0x128/0x1c0 [ib_core]\n   ib_create_qp_kernel+0x50/0xd0 [ib_core]\n   create_mad_qp+0x8e/0xe0 [ib_core]\n   ? __pfx_qp_event_handler+0x10/0x10 [ib_core]\n   ib_mad_init_device+0x2be/0x680 [ib_core]\n   add_client_context+0x10d/0x1a0 [ib_core]\n   enable_device_and_get+0xe0/0x1d0 [ib_core]\n   ib_register_device+0x53c/0x630 [ib_core]\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   bnxt_re_probe+0xbd8/0xe50 [bnxt_re]\n   ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]\n   auxiliary_bus_probe+0x49/0x80\n   ? driver_sysfs_add+0x57/0xc0\n   really_probe+0xde/0x340\n   ? pm_runtime_barrier+0x54/0x90\n   ? __pfx___driver_attach+0x10/0x10\n   __driver_probe_device+0x78/0x110\n   driver_probe_device+0x1f/0xa0\n   __driver_attach+0xba/0x1c0\n   bus_for_each_dev+0x8f/0xe0\n   bus_add_driver+0x146/0x220\n   driver_register+0x72/0xd0\n   __auxiliary_driver_register+0x6e/0xd0\n   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n   bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]\n   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n   do_one_initcall+0x5b/0x310\n   do_init_module+0x90/0x250\n   init_module_from_file+0x86/0xc0\n   idempotent_init_module+0x121/0x2b0\n   __x64_sys_finit_module+0x5e/0xb0\n   do_syscall_64+0x82/0x160\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? syscall_exit_to_user_mode_prepare+0x149/0x170\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? syscall_exit_to_user_mode+0x75/0x230\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? do_syscall_64+0x8e/0x160\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? __count_memcg_events+0x69/0x100\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? count_memcg_events.constprop.0+0x1a/0x30\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? handle_mm_fault+0x1f0/0x300\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? do_user_addr_fault+0x34e/0x640\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  RIP: 0033:0x7f4e5132821d\n  Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48\n  RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139\n  RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d\n  RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b\n  RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0\n  R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d\n  R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace ]---(CVE-2024-38540)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: openvswitch: fix overwriting ct original tuple for ICMPv6\r\n\r\nOVS_PACKET_CMD_EXECUTE has 3 main attributes:\n - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.\n - OVS_PACKET_ATTR_PACKET - Binary packet content.\n - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.\r\n\r\nOVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure\nwith the metadata like conntrack state, input port, recirculation id,\netc.  Then the packet itself gets parsed to populate the rest of the\nkeys from the packet headers.\r\n\r\nWhenever the packet parsing code starts parsing the ICMPv6 header, it\nfirst zeroes out fields in the key corresponding to Neighbor Discovery\ninformation even if it is not an ND packet.\r\n\r\nIt is an \u0026apos;ipv6.nd\u0026apos; field.  However, the \u0026apos;ipv6\u0026apos; is a union that shares\nthe space between \u0026apos;nd\u0026apos; and \u0026apos;ct_orig\u0026apos; that holds the original tuple\nconntrack metadata parsed from the OVS_PACKET_ATTR_KEY.\r\n\r\nND packets should not normally have conntrack state, so it\u0026apos;s fine to\nshare the space, but normal ICMPv6 Echo packets or maybe other types of\nICMPv6 can have the state attached and it should not be overwritten.\r\n\r\nThe issue results in all but the last 4 bytes of the destination\naddress being wiped from the original conntrack tuple leading to\nincorrect packet matching and potentially executing wrong actions\nin case this packet recirculates within the datapath or goes back\nto userspace.\r\n\r\nND fields should not be accessed in non-ND packets, so not clearing\nthem should be fine.  Executing memset() only for actual ND packets to\navoid the issue.\r\n\r\nInitializing the whole thing before parsing is needed because ND packet\nmay not contain all the options.\r\n\r\nThe issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn\u0026apos;t\naffect packets entering OVS datapath from network interfaces, because\nin this case CT metadata is populated from skb after the packet is\nalready parsed.(CVE-2024-38558)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: Fix potential glock use-after-free on unmount\r\n\r\nWhen a DLM lockspace is released and there ares still locks in that\nlockspace, DLM will unlock those locks automatically.  Commit\nfb6791d100d1b started exploiting this behavior to speed up filesystem\nunmount: gfs2 would simply free glocks it didn\u0026apos;t want to unlock and then\nrelease the lockspace.  This didn\u0026apos;t take the bast callbacks for\nasynchronous lock contention notifications into account, which remain\nactive until until a lock is unlocked or its lockspace is released.\r\n\r\nTo prevent those callbacks from accessing deallocated objects, put the\nglocks that should not be unlocked on the sd_dead_glocks list, release\nthe lockspace, and only then free those glocks.\r\n\r\nAs an additional measure, ignore unexpected ast and bast callbacks if\nthe receiving glock is dead.(CVE-2024-38570)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\r\n\r\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\r\n\r\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\r\n\r\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied.(CVE-2024-38586)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: core: Fix NULL module pointer assignment at card init\r\n\r\nThe commit 81033c6b584b (\u0026quot;ALSA: core: Warn on empty module\u0026quot;)\nintroduced a WARN_ON() for a NULL module pointer passed at snd_card\nobject creation, and it also wraps the code around it with \u0026apos;#ifdef\nMODULE\u0026apos;.  This works in most cases, but the devils are always in\ndetails.  \u0026quot;MODULE\u0026quot; is defined when the target code (i.e. the sound\ncore) is built as a module; but this doesn\u0026apos;t mean that the caller is\nalso built-in or not.  Namely, when only the sound core is built-in\n(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),\nthe passed module pointer is ignored even if it\u0026apos;s non-NULL, and\ncard-\u0026gt;module remains as NULL.  This would result in the missing module\nreference up/down at the device open/close, leading to a race with the\ncode execution after the module removal.\r\n\r\nFor addressing the bug, move the assignment of card-\u0026gt;module again out\nof ifdef.  The WARN_ON() is still wrapped with ifdef because the\nmodule can be really NULL when all sound drivers are built-in.\r\n\r\nNote that we keep \u0026apos;ifdef MODULE\u0026apos; for WARN_ON(), otherwise it would\nlead to a false-positive NULL module check.  Admittedly it won\u0026apos;t catch\nperfectly, i.e. no check is performed when CONFIG_SND=y.  But, it\u0026apos;s no\nreal problem as it\u0026apos;s only for debugging, and the condition is pretty\nrare.(CVE-2024-38605)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: fix potential memory leak in vfio_intx_enable()\r\n\r\nIf vfio_irq_ctx_alloc() failed will lead to \u0026apos;name\u0026apos; memory leak.(CVE-2024-38632)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkdb: Fix buffer overflow during tab-complete\r\n\r\nCurrently, when the user attempts symbol completion with the Tab key, kdb\nwill use strncpy() to insert the completed symbol into the command buffer.\nUnfortunately it passes the size of the source buffer rather than the\ndestination to strncpy() with predictably horrible results. Most obviously\nif the command buffer is already full but cp, the cursor position, is in\nthe middle of the buffer, then we will write past the end of the supplied\nbuffer.\r\n\r\nFix this by replacing the dubious strncpy() calls with memmove()/memcpy()\ncalls plus explicit boundary checks to make sure we have enough space\nbefore we start moving characters around.(CVE-2024-39480)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()\r\n\r\nIn function bond_option_arp_ip_targets_set(), if newval-\u0026gt;string is an\nempty string, newval-\u0026gt;string+1 will point to the byte after the\nstring, causing an out-of-bound read.\r\n\r\nBUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418\nRead of size 1 at addr ffff8881119c4781 by task syz-executor665/8107\nCPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:364 [inline]\n print_report+0xc1/0x5e0 mm/kasan/report.c:475\n kasan_report+0xbe/0xf0 mm/kasan/report.c:588\n strlen+0x7d/0xa0 lib/string.c:418\n __fortify_strlen include/linux/fortify-string.h:210 [inline]\n in4_pton+0xa3/0x3f0 net/core/utils.c:130\n bond_option_arp_ip_targets_set+0xc2/0x910\ndrivers/net/bonding/bond_options.c:1201\n __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767\n __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792\n bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817\n bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156\n dev_attr_store+0x54/0x80 drivers/base/core.c:2366\n sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136\n kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x96a/0xd80 fs/read_write.c:584\n ksys_write+0x122/0x250 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n---[ end trace ]---\r\n\r\nFix it by adding a check of string length before using it.(CVE-2024-39487)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY\r\n\r\nWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes\nto bug_table entries, and as a result the last entry in a bug table will\nbe ignored, potentially leading to an unexpected panic(). All prior\nentries in the table will be handled correctly.\r\n\r\nThe arm64 ABI requires that struct fields of up to 8 bytes are\nnaturally-aligned, with padding added within a struct such that struct\nare suitably aligned within arrays.\r\n\r\nWhen CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:\r\n\r\n\tstruct bug_entry {\n\t\tsigned int      bug_addr_disp;\t// 4 bytes\n\t\tsigned int      file_disp;\t// 4 bytes\n\t\tunsigned short  line;\t\t// 2 bytes\n\t\tunsigned short  flags;\t\t// 2 bytes\n\t}\r\n\r\n... with 12 bytes total, requiring 4-byte alignment.\r\n\r\nWhen CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:\r\n\r\n\tstruct bug_entry {\n\t\tsigned int      bug_addr_disp;\t// 4 bytes\n\t\tunsigned short  flags;\t\t// 2 bytes\n\t\t\u0026lt; implicit padding \u0026gt;\t\t// 2 bytes\n\t}\r\n\r\n... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing\npadding, requiring 4-byte alginment.\r\n\r\nWhen we create a bug_entry in assembly, we align the start of the entry\nto 4 bytes, which implicitly handles padding for any prior entries.\nHowever, we do not align the end of the entry, and so when\nCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding\nbytes.\r\n\r\nFor the main kernel image this is not a problem as find_bug() doesn\u0026apos;t\ndepend on the trailing padding bytes when searching for entries:\r\n\r\n\tfor (bug = __start___bug_table; bug \u0026lt; __stop___bug_table; ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\treturn bug;\r\n\r\nHowever for modules, module_bug_finalize() depends on the trailing\nbytes when calculating the number of entries:\r\n\r\n\tmod-\u0026gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);\r\n\r\n... and as the last bug_entry lacks the necessary padding bytes, this entry\nwill not be counted, e.g. in the case of a single entry:\r\n\r\n\tsechdrs[i].sh_size == 6\n\tsizeof(struct bug_entry) == 8;\r\n\r\n\tsechdrs[i].sh_size / sizeof(struct bug_entry) == 0;\r\n\r\nConsequently module_find_bug() will miss the last bug_entry when it does:\r\n\r\n\tfor (i = 0; i \u0026lt; mod-\u0026gt;num_bugs; ++i, ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\tgoto out;\r\n\r\n... which can lead to a kenrel panic due to an unhandled bug.\r\n\r\nThis can be demonstrated with the following module:\r\n\r\n\tstatic int __init buginit(void)\n\t{\n\t\tWARN(1, \u0026quot;hello\\n\u0026quot;);\n\t\treturn 0;\n\t}\r\n\r\n\tstatic void __exit bugexit(void)\n\t{\n\t}\r\n\r\n\tmodule_init(buginit);\n\tmodule_exit(bugexit);\n\tMODULE_LICENSE(\u0026quot;GPL\u0026quot;);\r\n\r\n... which will trigger a kernel panic when loaded:\r\n\r\n\t------------[ cut here ]------------\n\thello\n\tUnexpected kernel BRK exception at EL1\n\tInternal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP\n\tModules linked in: hello(O+)\n\tCPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8\n\tHardware name: linux,dummy-virt (DT)\n\tpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n\tpc : buginit+0x18/0x1000 [hello]\n\tlr : buginit+0x18/0x1000 [hello]\n\tsp : ffff800080533ae0\n\tx29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000\n\tx26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58\n\tx23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0\n\tx20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006\n\tx17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720\n\tx14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312\n\tx11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8\n\tx8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000\n\tx5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000\n\tx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0\n\tCall trace:\n\t buginit+0x18/0x1000 [hello]\n\t do_one_initcall+0x80/0x1c8\n\t do_init_module+0x60/0x218\n\t load_module+0x1ba4/0x1d70\n\t __do_sys_init_module+0x198/0x1d0\n\t __arm64_sys_init_module+0x1c/0x28\n\t invoke_syscall+0x48/0x114\n\t el0_svc\n---truncated---(CVE-2024-39488)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix memleak in seg6_hmac_init_algo\r\n\r\nseg6_hmac_init_algo returns without cleaning up the previous allocations\nif one fails, so it\u0026apos;s going to leak all that memory and the crypto tfms.\r\n\r\nUpdate seg6_hmac_exit to only free the memory when allocated, so we can\nreuse the code directly.(CVE-2024-39489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsock_map: avoid race between sock_map_close and sk_psock_put\r\n\r\nsk_psock_get will return NULL if the refcount of psock has gone to 0, which\nwill happen when the last call of sk_psock_put is done. However,\nsk_psock_drop may not have finished yet, so the close callback will still\npoint to sock_map_close despite psock being NULL.\r\n\r\nThis can be reproduced with a thread deleting an element from the sock map,\nwhile the second one creates a socket, adds it to the map and closes it.\r\n\r\nThat will trigger the WARN_ON_ONCE:\r\n\r\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nModules linked in:\nCPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nCode: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 \u0026lt;0f\u0026gt; 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02\nRSP: 0018:ffffc9000441fda8 EFLAGS: 00010293\nRAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000\nRDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0\nRBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3\nR10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840\nR13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870\nFS:  000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n unix_release+0x87/0xc0 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0xbe/0x240 net/socket.c:1421\n __fput+0x42b/0x8a0 fs/file_table.c:422\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close fs/open.c:1541 [inline]\n __x64_sys_close+0x7f/0x110 fs/open.c:1541\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fb37d618070\nCode: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c\nRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003\nRAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070\nRDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\r\n\r\nUse sk_psock, which will only check that the pointer is not been set to\nNULL yet, which should only happen after the callbacks are restored. If,\nthen, a reference can still be gotten, we may call sk_psock_stop and cancel\npsock-\u0026gt;work.\r\n\r\nAs suggested by Paolo Abeni, reorder the condition so the control flow is\nless convoluted.\r\n\r\nAfter that change, the reproducer does not trigger the WARN_ON_ONCE\nanymore.(CVE-2024-39500)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nionic: fix use after netif_napi_del()\r\n\r\nWhen queues are started, netif_napi_add() and napi_enable() are called.\nIf there are 4 queues and only 3 queues are used for the current\nconfiguration, only 3 queues\u0026apos; napi should be registered and enabled.\nThe ionic_qcq_enable() checks whether the .poll pointer is not NULL for\nenabling only the using queue\u0026apos; napi. Unused queues\u0026apos; napi will not be\nregistered by netif_napi_add(), so the .poll pointer indicates NULL.\nBut it couldn\u0026apos;t distinguish whether the napi was unregistered or not\nbecause netif_napi_del() doesn\u0026apos;t reset the .poll pointer to NULL.\nSo, ionic_qcq_enable() calls napi_enable() for the queue, which was\nunregistered by netif_napi_del().\r\n\r\nReproducer:\n   ethtool -L \u0026lt;interface name\u0026gt; rx 1 tx 1 combined 0\n   ethtool -L \u0026lt;interface name\u0026gt; rx 0 tx 0 combined 1\n   ethtool -L \u0026lt;interface name\u0026gt; rx 0 tx 0 combined 4\r\n\r\nSplat looks like:\nkernel BUG at net/core/dev.c:6666!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16\nWorkqueue: events ionic_lif_deferred_work [ionic]\nRIP: 0010:napi_enable+0x3b/0x40\nCode: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f\nRSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029\nRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28\nRBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001\nR10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000\nR13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20\nFS:  0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die+0x33/0x90\n ? do_trap+0xd9/0x100\n ? napi_enable+0x3b/0x40\n ? do_error_trap+0x83/0xb0\n ? napi_enable+0x3b/0x40\n ? napi_enable+0x3b/0x40\n ? exc_invalid_op+0x4e/0x70\n ? napi_enable+0x3b/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? napi_enable+0x3b/0x40\n ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\n ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\n ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\n ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\n process_one_work+0x145/0x360\n worker_thread+0x2bb/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xcc/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30(CVE-2024-39502)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: ensure snd_una is properly initialized on connect\r\n\r\nThis is strictly related to commit fb7a0d334894 (\u0026quot;mptcp: ensure snd_nxt\nis properly initialized on connect\u0026quot;). It turns out that syzkaller can\ntrigger the retransmit after fallback and before processing any other\nincoming packet - so that snd_una is still left uninitialized.\r\n\r\nAddress the issue explicitly initializing snd_una together with snd_nxt\nand write_seq.(CVE-2024-40931)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()\r\n\r\nFix a memory leak on logi_dj_recv_send_report() error path.(CVE-2024-40934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: remove clear SB_INLINECRYPT flag in default_options\r\n\r\nIn f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.\nIf create new file or open file during this gap, these files\nwill not use inlinecrypt. Worse case, it may lead to data\ncorruption if wrappedkey_v0 is enable.\r\n\r\nThread A:                               Thread B:\r\n\r\n-f2fs_remount\t\t\t\t-f2fs_file_open or f2fs_new_inode\n  -default_options\n\t\u0026lt;- clear SB_INLINECRYPT flag\r\n\r\n                                          -fscrypt_select_encryption_impl\r\n\r\n  -parse_options\n\t\u0026lt;- set SB_INLINECRYPT again(CVE-2024-40971)",
  "id": "OESA-2024-1861",
  "modified": "2026-08-06T11:07:19Z",
  "published": "2024-07-19T11:07:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1861"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34027"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36478"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38540"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38558"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38570"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38586"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38605"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38632"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39480"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39487"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39488"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39489"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39500"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39502"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40931"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40971"
    }
  ],
  "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-2023-52755",
    "CVE-2024-34027",
    "CVE-2024-36478",
    "CVE-2024-38540",
    "CVE-2024-38558",
    "CVE-2024-38570",
    "CVE-2024-38586",
    "CVE-2024-38605",
    "CVE-2024-38632",
    "CVE-2024-39480",
    "CVE-2024-39487",
    "CVE-2024-39488",
    "CVE-2024-39489",
    "CVE-2024-39500",
    "CVE-2024-39502",
    "CVE-2024-40931",
    "CVE-2024-40934",
    "CVE-2024-40971"
  ]
}

OESA-2024-1863 (CVE-2024-36017)

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

rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation

Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a struct ifla_vf_vlan_info so the size of such attribute needs to be at least of sizeof(struct ifla_vf_vlan_info) which is 14 bytes. The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes) which is less than sizeof(struct ifla_vf_vlan_info) so this validation is not enough and a too small attribute might be cast to a struct ifla_vf_vlan_info, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)

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

null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'

Writing 'power' and 'submit_queues' concurrently will trigger kernel panic:

Test script:

modprobe null_blk nr_devices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submit_queues; echo 4 > submit_queues; done & while true; do echo 1 > power; echo 0 > power; done

Test result:

This is because del_gendisk() can concurrent with blk_mq_update_nr_hw_queues():

Fix this problem by resuing the global mutex to protect nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)

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

tracing/probes: fix error check in parse_btf_field()

btf_find_struct_member() might return NULL or an error via the ERR_PTR() macro. However, its caller in parse_btf_field() only checks for the NULL condition. Fix this by using IS_ERR() and returning the error up the stack.(CVE-2024-36481)

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

scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()

lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock.(CVE-2024-36924)

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

net: core: reject skb_copy(_expand) for fraglist GSO skbs

SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment.(CVE-2024-36929)

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

s390/cio: Ensure the copied buf is NUL terminated

Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from userspace to that buffer. Later, we use scanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using scanf. Fix this issue by using memdup_user_nul instead.(CVE-2024-36931)

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

drm/amdkfd: range check cp bad op exception interrupts

Due to a CP interrupt bug, bad packet garbage exception codes are raised. Do a range check so that the debugger and runtime do not receive garbage codes. Update the user api to guard exception code type checking as well.(CVE-2024-36951)

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

blk-cgroup: fix list corruption from reorder of WRITE ->lqueued

__blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start is being executed.

If WRITE of ->lqueued is re-ordered with READ of 'bisc->lnode.next' in the loop of __blkcg_rstat_flush(), next_bisc can be assigned with one stat instance being added in blk_cgroup_bio_start(), then the local list in __blkcg_rstat_flush() could be corrupted.

Fix the issue by adding one barrier.(CVE-2024-38384)

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

net: openvswitch: fix overwriting ct original tuple for ICMPv6

Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet.

It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.

ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue.

Initializing the whole thing before parsing is needed because ND packet may not contain all the options.

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

gfs2: Fix potential glock use-after-free on unmount

To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.

As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.(CVE-2024-38570)

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

drm/amdgpu/mes: fix use-after-free issue

Delete fence fallback timer to fix the ramdom use-after-free issue.

v2: move to amdgpu_mes.c(CVE-2024-38581)

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

nilfs2: fix use-after-free of timer for log writer thread

Patch series "nilfs2: fix log writer related issues".

This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log.

This patch (of 3):

A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure.

The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime.

Fix this issue by limiting the use of sc_timer only while the log writer thread is alive.(CVE-2024-38583)

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

r8169: Fix possible ring buffer corruption on fragmented Tx packets.

This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2().

To fix this, postpone inspecting nr_frags until after any padding has been applied.(CVE-2024-38586)

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

openrisc: traps: Don't send signals to kernel mode threads

OpenRISC exception handling sends signals to user processes on floating point exceptions and trap instructions (for debugging) among others. There is a bug where the trap handling logic may send signals to kernel threads, we should not send these signals to kernel threads, if that happens we treat it as an error.

This patch adds conditions to die if the kernel receives these exceptions in kernel mode code.(CVE-2024-38614)

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

Bluetooth: HCI: Remove HCI_AMP support

Since BT_HS has been remove HCI_AMP controllers no longer has any use so remove it along with the capability of creating AMP controllers.

Since we no longer need to differentiate between AMP and Primary controllers, as only HCI_PRIMARY is left, this also remove hdev->dev_type altogether.(CVE-2024-38620)

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

vfio/pci: fix potential memory leak in vfio_intx_enable()

If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.(CVE-2024-38632)

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

s390/ap: Fix crash in AP internal function modify_bitmap()

A system crash like this

Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oops

occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.

The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow.(CVE-2024-38661)

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

clk: bcm: dvp: Assign ->num before accessing ->hws

Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in clk_dvp_probe() due to ->num being assigned after ->hws has been accessed:

UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2 index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')

Move the ->num initialization to before the first access of ->hws, which clears up the warning.(CVE-2024-39462)

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

media: v4l: async: Fix notifier list entry init

struct v4l2_async_notifier has several list_head members, but only waiting_list and done_list are initialized. notifier_entry was kept 'zeroed' leading to an uninitialized list_head. This results in a NULL-pointer dereference if csi2_async_register() fails, e.g. node for remote endpoint is disabled, and returns -ENOTCONN. The following calls to v4l2_async_nf_unregister() results in a NULL pointer dereference. Add the missing list head initializer.(CVE-2024-39464)

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

crypto: starfive - Do not free stack buffer

RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations.(CVE-2024-39478)

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

drm/i915/hwmon: Get rid of devm

When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below):

Call Trace: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0 component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0

and

Call Trace: release_nodes+0x11/0x70 devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0

This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't.

The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind.

v2: Change commit message and other minor code changes v3: Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)(CVE-2024-39479)

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

kdb: Fix buffer overflow during tab-complete

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

bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()

In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read.

Fix it by adding a check of string length before using it.(CVE-2024-39487)

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

arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY

The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays.

When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:

struct bug_entry {
    signed int      bug_addr_disp;  // 4 bytes
    signed int      file_disp;  // 4 bytes
    unsigned short  line;       // 2 bytes
    unsigned short  flags;      // 2 bytes
}

... with 12 bytes total, requiring 4-byte alignment.

When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:

struct bug_entry {
    signed int      bug_addr_disp;  // 4 bytes
    unsigned short  flags;      // 2 bytes
    &lt; implicit padding &gt;      // 2 bytes
}

... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment.

For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries:

for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug)
    if (bugaddr == bug_addr(bug))
        return bug;

However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries:

mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);

... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry:

sechdrs[i].sh_size == 6
sizeof(struct bug_entry) == 8;

sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;

Consequently module_find_bug() will miss the last bug_entry when it does:

for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug)
    if (bugaddr == bug_addr(bug))
        goto out;

... which can lead to a kenrel panic due to an unhandled bug.

This can be demonstrated with the following module:

static int __init buginit(void)
{
    WARN(1, &quot;hello\n&quot;);
    return 0;
}

static void __exit bugexit(void)
{
}

module_init(buginit);
module_exit(bugexit);
MODULE_LICENSE(&quot;GPL&quot;);

... which will trigger a kernel panic when loaded:

------------[ cut here ]------------
hello
Unexpected kernel BRK exception at EL1
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in: hello(O+)
CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8
Hardware name: linux,dummy-virt (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : buginit+0x18/0x1000 [hello]
lr : buginit+0x18/0x1000 [hello]
sp : ffff800080533ae0
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
Call trace:
 buginit+0x18/0x1000 [hello]
 do_one_initcall+0x80/0x1c8
 do_init_module+0x60/0x218
 load_module+0x1ba4/0x1d70
 __do_sys_init_module+0x198/0x1d0
 __arm64_sys_init_module+0x1c/0x28
 invoke_syscall+0x48/0x114
 el0_svc

---truncated---(CVE-2024-39488)

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

ipv6: sr: fix memleak in seg6_hmac_init_algo

seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms.

Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly.(CVE-2024-39489)

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

sock_map: avoid race between sock_map_close and sk_psock_put

This can be reproduced with a thread deleting an element from the sock map, while the second one creates a socket, adds it to the map and closes it.

That will trigger the WARN_ON_ONCE:

As suggested by Paolo Abeni, reorder the condition so the control flow is less convoluted.

After that change, the reproducer does not trigger the WARN_ON_ONCE anymore.(CVE-2024-39500)

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

ionic: fix use after netif_napi_del()

Reproducer: ethtool -L <interface name> rx 1 tx 1 combined 0 ethtool -L <interface name> rx 0 tx 0 combined 1 ethtool -L <interface name> rx 0 tx 0 combined 4

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

ipv6: fix possible race in __fib6_drop_pcpu_from()

syzbot found a race in __fib6_drop_pcpu_from() [1]

If compiler reads more than once (*ppcpu_rt), second read could read NULL, if another cpu clears the value in rt6_get_pcpu_route().

Add a READ_ONCE() to prevent this race.

Also add rcu_read_lock()/rcu_read_unlock() because we rely on RCU protection while dereferencing pcpu_rt.

[1]

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40905)

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

mptcp: ensure snd_una is properly initialized on connect

Address the issue explicitly initializing snd_una together with snd_nxt and write_seq.(CVE-2024-40931)

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

HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()

Fix a memory leak on logi_dj_recv_send_report() error path.(CVE-2024-40934)

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

ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()

The cs35l41_hda_unbind() function clears the hda_component entry matching it's index and then dereferences the codec pointer held in the first element of the hda_component array, this is an issue when the device index was 0.

Instead use the codec pointer stashed in the cs35l41_hda structure as it will still be valid.(CVE-2024-40964)

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

f2fs: remove clear SB_INLINECRYPT flag in default_options

Thread A: Thread B:

-f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag

                                      -fscrypt_select_encryption_impl

-parse_options <- set SB_INLINECRYPT again(CVE-2024-40971)

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

cpufreq: amd-pstate: fix memory leak on CPU EPP exit

The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is not freed in the analogous exit function, so fix that.

rjw: Subject and changelog edits

Severity

9.8 (Critical)


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

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36017	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36478	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36481	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36924	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36929	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36931	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36951	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38384	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38558	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38570	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38581	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38583	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38586	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38614	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38620	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38632	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38661	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39462	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39464	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39478	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39479	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39480	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39487	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39488	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39489	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39500	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39502	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40905	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40931	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40934	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40964	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40971	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40997	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "kernel-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "perf-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-34.0.0.41.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-34.0.0.41.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-34.0.0.41.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "kernel-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "perf-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-34.0.0.41.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-34.0.0.41.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-34.0.0.41.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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\nrtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation\r\n\r\nEach attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a\nstruct ifla_vf_vlan_info so the size of such attribute needs to be at least\nof sizeof(struct ifla_vf_vlan_info) which is 14 bytes.\nThe current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)\nwhich is less than sizeof(struct ifla_vf_vlan_info) so this validation\nis not enough and a too small attribute might be cast to a\nstruct ifla_vf_vlan_info, this might result in an out of bands\nread access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnull_blk: fix null-ptr-dereference while configuring \u0026apos;power\u0026apos; and \u0026apos;submit_queues\u0026apos;\r\n\r\nWriting \u0026apos;power\u0026apos; and \u0026apos;submit_queues\u0026apos; concurrently will trigger kernel\npanic:\r\n\r\nTest script:\r\n\r\nmodprobe null_blk nr_devices=0\nmkdir -p /sys/kernel/config/nullb/nullb0\nwhile true; do echo 1 \u0026gt; submit_queues; echo 4 \u0026gt; submit_queues; done \u0026amp;\nwhile true; do echo 1 \u0026gt; power; echo 0 \u0026gt; power; done\r\n\r\nTest result:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000148\nOops: 0000 [#1] PREEMPT SMP\nRIP: 0010:__lock_acquire+0x41d/0x28f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n lock_acquire+0x121/0x450\n down_write+0x5f/0x1d0\n simple_recursive_removal+0x12f/0x5c0\n blk_mq_debugfs_unregister_hctxs+0x7c/0x100\n blk_mq_update_nr_hw_queues+0x4a3/0x720\n nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]\n nullb_device_submit_queues_store+0x79/0xf0 [null_blk]\n configfs_write_iter+0x119/0x1e0\n vfs_write+0x326/0x730\n ksys_write+0x74/0x150\r\n\r\nThis is because del_gendisk() can concurrent with\nblk_mq_update_nr_hw_queues():\r\n\r\nnullb_device_power_store\tnullb_apply_submit_queues\n null_del_dev\n del_gendisk\n\t\t\t\t nullb_update_nr_hw_queues\n\t\t\t\t  if (!dev-\u0026gt;nullb)\n\t\t\t\t  // still set while gendisk is deleted\n\t\t\t\t   return 0\n\t\t\t\t  blk_mq_update_nr_hw_queues\n dev-\u0026gt;nullb = NULL\r\n\r\nFix this problem by resuing the global mutex to protect\nnullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing/probes: fix error check in parse_btf_field()\r\n\r\nbtf_find_struct_member() might return NULL or an error via the\nERR_PTR() macro. However, its caller in parse_btf_field() only checks\nfor the NULL condition. Fix this by using IS_ERR() and returning the\nerror up the stack.(CVE-2024-36481)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()\r\n\r\nlpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the\nhbalock.  Thus, lpfc_worker_wake_up() should not be called while holding the\nhbalock to avoid potential deadlock.(CVE-2024-36924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: core: reject skb_copy(_expand) for fraglist GSO skbs\r\n\r\nSKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become\ninvalid. Return NULL if such an skb is passed to skb_copy or\nskb_copy_expand, in order to prevent a crash on a potential later\ncall to skb_gso_segment.(CVE-2024-36929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/cio: Ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a lbuf-sized kernel buffer and copy lbuf from\nuserspace to that buffer. Later, we use scanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using scanf. Fix this issue by using memdup_user_nul instead.(CVE-2024-36931)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdkfd: range check cp bad op exception interrupts\r\n\r\nDue to a CP interrupt bug, bad packet garbage exception codes are raised.\nDo a range check so that the debugger and runtime do not receive garbage\ncodes.\nUpdate the user api to guard exception code type checking as well.(CVE-2024-36951)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-cgroup: fix list corruption from reorder of WRITE -\u0026gt;lqueued\r\n\r\n__blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start\nis being executed.\r\n\r\nIf WRITE of `-\u0026gt;lqueued` is re-ordered with READ of \u0026apos;bisc-\u0026gt;lnode.next\u0026apos; in\nthe loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one\nstat instance being added in blk_cgroup_bio_start(), then the local\nlist in __blkcg_rstat_flush() could be corrupted.\r\n\r\nFix the issue by adding one barrier.(CVE-2024-38384)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: openvswitch: fix overwriting ct original tuple for ICMPv6\r\n\r\nOVS_PACKET_CMD_EXECUTE has 3 main attributes:\n - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.\n - OVS_PACKET_ATTR_PACKET - Binary packet content.\n - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.\r\n\r\nOVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure\nwith the metadata like conntrack state, input port, recirculation id,\netc.  Then the packet itself gets parsed to populate the rest of the\nkeys from the packet headers.\r\n\r\nWhenever the packet parsing code starts parsing the ICMPv6 header, it\nfirst zeroes out fields in the key corresponding to Neighbor Discovery\ninformation even if it is not an ND packet.\r\n\r\nIt is an \u0026apos;ipv6.nd\u0026apos; field.  However, the \u0026apos;ipv6\u0026apos; is a union that shares\nthe space between \u0026apos;nd\u0026apos; and \u0026apos;ct_orig\u0026apos; that holds the original tuple\nconntrack metadata parsed from the OVS_PACKET_ATTR_KEY.\r\n\r\nND packets should not normally have conntrack state, so it\u0026apos;s fine to\nshare the space, but normal ICMPv6 Echo packets or maybe other types of\nICMPv6 can have the state attached and it should not be overwritten.\r\n\r\nThe issue results in all but the last 4 bytes of the destination\naddress being wiped from the original conntrack tuple leading to\nincorrect packet matching and potentially executing wrong actions\nin case this packet recirculates within the datapath or goes back\nto userspace.\r\n\r\nND fields should not be accessed in non-ND packets, so not clearing\nthem should be fine.  Executing memset() only for actual ND packets to\navoid the issue.\r\n\r\nInitializing the whole thing before parsing is needed because ND packet\nmay not contain all the options.\r\n\r\nThe issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn\u0026apos;t\naffect packets entering OVS datapath from network interfaces, because\nin this case CT metadata is populated from skb after the packet is\nalready parsed.(CVE-2024-38558)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: Fix potential glock use-after-free on unmount\r\n\r\nWhen a DLM lockspace is released and there ares still locks in that\nlockspace, DLM will unlock those locks automatically.  Commit\nfb6791d100d1b started exploiting this behavior to speed up filesystem\nunmount: gfs2 would simply free glocks it didn\u0026apos;t want to unlock and then\nrelease the lockspace.  This didn\u0026apos;t take the bast callbacks for\nasynchronous lock contention notifications into account, which remain\nactive until until a lock is unlocked or its lockspace is released.\r\n\r\nTo prevent those callbacks from accessing deallocated objects, put the\nglocks that should not be unlocked on the sd_dead_glocks list, release\nthe lockspace, and only then free those glocks.\r\n\r\nAs an additional measure, ignore unexpected ast and bast callbacks if\nthe receiving glock is dead.(CVE-2024-38570)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu/mes: fix use-after-free issue\r\n\r\nDelete fence fallback timer to fix the ramdom\nuse-after-free issue.\r\n\r\nv2: move to amdgpu_mes.c(CVE-2024-38581)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix use-after-free of timer for log writer thread\r\n\r\nPatch series \u0026quot;nilfs2: fix log writer related issues\u0026quot;.\r\n\r\nThis bug fix series covers three nilfs2 log writer-related issues,\nincluding a timer use-after-free issue and potential deadlock issue on\nunmount, and a potential freeze issue in event synchronization found\nduring their analysis.  Details are described in each commit log.\r\n\r\n\nThis patch (of 3):\r\n\r\nA use-after-free issue has been reported regarding the timer sc_timer on\nthe nilfs_sc_info structure.\r\n\r\nThe problem is that even though it is used to wake up a sleeping log\nwriter thread, sc_timer is not shut down until the nilfs_sc_info structure\nis about to be freed, and is used regardless of the thread\u0026apos;s lifetime.\r\n\r\nFix this issue by limiting the use of sc_timer only while the log writer\nthread is alive.(CVE-2024-38583)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\r\n\r\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\r\n\r\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\r\n\r\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied.(CVE-2024-38586)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nopenrisc: traps: Don\u0026apos;t send signals to kernel mode threads\r\n\r\nOpenRISC exception handling sends signals to user processes on floating\npoint exceptions and trap instructions (for debugging) among others.\nThere is a bug where the trap handling logic may send signals to kernel\nthreads, we should not send these signals to kernel threads, if that\nhappens we treat it as an error.\r\n\r\nThis patch adds conditions to die if the kernel receives these\nexceptions in kernel mode code.(CVE-2024-38614)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: HCI: Remove HCI_AMP support\r\n\r\nSince BT_HS has been remove HCI_AMP controllers no longer has any use so\nremove it along with the capability of creating AMP controllers.\r\n\r\nSince we no longer need to differentiate between AMP and Primary\ncontrollers, as only HCI_PRIMARY is left, this also remove\nhdev-\u0026gt;dev_type altogether.(CVE-2024-38620)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: fix potential memory leak in vfio_intx_enable()\r\n\r\nIf vfio_irq_ctx_alloc() failed will lead to \u0026apos;name\u0026apos; memory leak.(CVE-2024-38632)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/ap: Fix crash in AP internal function modify_bitmap()\r\n\r\nA system crash like this\r\n\r\n  Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403\n  Fault in home space mode while using kernel ASCE.\n  AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d\n  Oops: 0038 ilc:3 [#1] PREEMPT SMP\n  Modules linked in: mlx5_ib ...\n  CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8\n  Hardware name: IBM 3931 A01 704 (LPAR)\n  Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)\n  R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3\n  Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3\n  000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0\n  000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff\n  000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8\n  Krnl Code: 0000014b75e7b5fc: a7840047            brc     8,0000014b75e7b68a\n  0000014b75e7b600: 18b2                lr      %r11,%r2\n  #0000014b75e7b602: a7f4000a            brc     15,0000014b75e7b616\n  \u0026gt;0000014b75e7b606: eb22d00000e6        laog    %r2,%r2,0(%r13)\n  0000014b75e7b60c: a7680001            lhi     %r6,1\n  0000014b75e7b610: 187b                lr      %r7,%r11\n  0000014b75e7b612: 84960021            brxh    %r9,%r6,0000014b75e7b654\n  0000014b75e7b616: 18e9                lr      %r14,%r9\n  Call Trace:\n  [\u0026lt;0000014b75e7b606\u0026gt;] ap_parse_bitmap_str+0x10e/0x1f8\n  ([\u0026lt;0000014b75e7b5dc\u0026gt;] ap_parse_bitmap_str+0xe4/0x1f8)\n  [\u0026lt;0000014b75e7b758\u0026gt;] apmask_store+0x68/0x140\n  [\u0026lt;0000014b75679196\u0026gt;] kernfs_fop_write_iter+0x14e/0x1e8\n  [\u0026lt;0000014b75598524\u0026gt;] vfs_write+0x1b4/0x448\n  [\u0026lt;0000014b7559894c\u0026gt;] ksys_write+0x74/0x100\n  [\u0026lt;0000014b7618a440\u0026gt;] __do_syscall+0x268/0x328\n  [\u0026lt;0000014b761a3558\u0026gt;] system_call+0x70/0x98\n  INFO: lockdep is turned off.\n  Last Breaking-Event-Address:\n  [\u0026lt;0000014b75e7b636\u0026gt;] ap_parse_bitmap_str+0x13e/0x1f8\n  Kernel panic - not syncing: Fatal exception: panic_on_oops\r\n\r\noccured when /sys/bus/ap/a[pq]mask was updated with a relative mask value\n(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.\r\n\r\nThe fix is simple: use unsigned long values for the internal variables. The\ncorrect checks are already in place in the function but a simple int for\nthe internal variables was used with the possibility to overflow.(CVE-2024-38661)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: bcm: dvp: Assign -\u0026gt;num before accessing -\u0026gt;hws\r\n\r\nCommit f316cdff8d67 (\u0026quot;clk: Annotate struct clk_hw_onecell_data with\n__counted_by\u0026quot;) annotated the hws member of \u0026apos;struct clk_hw_onecell_data\u0026apos;\nwith __counted_by, which informs the bounds sanitizer about the number\nof elements in hws, so that it can warn when hws is accessed out of\nbounds. As noted in that change, the __counted_by member must be\ninitialized with the number of elements before the first array access\nhappens, otherwise there will be a warning from each access prior to the\ninitialization because the number of elements is zero. This occurs in\nclk_dvp_probe() due to -\u0026gt;num being assigned after -\u0026gt;hws has been\naccessed:\r\n\r\n  UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2\n  index 0 is out of range for type \u0026apos;struct clk_hw *[] __counted_by(num)\u0026apos; (aka \u0026apos;struct clk_hw *[]\u0026apos;)\r\n\r\nMove the -\u0026gt;num initialization to before the first access of -\u0026gt;hws, which\nclears up the warning.(CVE-2024-39462)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: v4l: async: Fix notifier list entry init\r\n\r\nstruct v4l2_async_notifier has several list_head members, but only\nwaiting_list and done_list are initialized. notifier_entry was kept\n\u0026apos;zeroed\u0026apos; leading to an uninitialized list_head.\nThis results in a NULL-pointer dereference if csi2_async_register() fails,\ne.g. node for remote endpoint is disabled, and returns -ENOTCONN.\nThe following calls to v4l2_async_nf_unregister() results in a NULL\npointer dereference.\nAdd the missing list head initializer.(CVE-2024-39464)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: starfive - Do not free stack buffer\r\n\r\nRSA text data uses variable length buffer allocated in software stack.\nCalling kfree on it causes undefined behaviour in subsequent operations.(CVE-2024-39478)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/hwmon: Get rid of devm\r\n\r\nWhen both hwmon and hwmon drvdata (on which hwmon depends) are device\nmanaged resources, the expectation, on device unbind, is that hwmon will be\nreleased before drvdata. However, in i915 there are two separate code\npaths, which both release either drvdata or hwmon and either can be\nreleased before the other. These code paths (for device unbind) are as\nfollows (see also the bug referenced below):\r\n\r\nCall Trace:\nrelease_nodes+0x11/0x70\ndevres_release_group+0xb2/0x110\ncomponent_unbind_all+0x8d/0xa0\ncomponent_del+0xa5/0x140\nintel_pxp_tee_component_fini+0x29/0x40 [i915]\nintel_pxp_fini+0x33/0x80 [i915]\ni915_driver_remove+0x4c/0x120 [i915]\ni915_pci_remove+0x19/0x30 [i915]\npci_device_remove+0x32/0xa0\ndevice_release_driver_internal+0x19c/0x200\nunbind_store+0x9c/0xb0\r\n\r\nand\r\n\r\nCall Trace:\nrelease_nodes+0x11/0x70\ndevres_release_all+0x8a/0xc0\ndevice_unbind_cleanup+0x9/0x70\ndevice_release_driver_internal+0x1c1/0x200\nunbind_store+0x9c/0xb0\r\n\r\nThis means that in i915, if use devm, we cannot gurantee that hwmon will\nalways be released before drvdata. Which means that we have a uaf if hwmon\nsysfs is accessed when drvdata has been released but hwmon hasn\u0026apos;t.\r\n\r\nThe only way out of this seems to be do get rid of devm_ and release/free\neverything explicitly during device unbind.\r\n\r\nv2: Change commit message and other minor code changes\nv3: Cleanup from i915_hwmon_register on error (Armin Wolf)\nv4: Eliminate potential static analyzer warning (Rodrigo)\n    Eliminate fetch_and_zero (Jani)\nv5: Restore previous logic for ddat_gt-\u0026gt;hwmon_dev error return (Andi)(CVE-2024-39479)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkdb: Fix buffer overflow during tab-complete\r\n\r\nCurrently, when the user attempts symbol completion with the Tab key, kdb\nwill use strncpy() to insert the completed symbol into the command buffer.\nUnfortunately it passes the size of the source buffer rather than the\ndestination to strncpy() with predictably horrible results. Most obviously\nif the command buffer is already full but cp, the cursor position, is in\nthe middle of the buffer, then we will write past the end of the supplied\nbuffer.\r\n\r\nFix this by replacing the dubious strncpy() calls with memmove()/memcpy()\ncalls plus explicit boundary checks to make sure we have enough space\nbefore we start moving characters around.(CVE-2024-39480)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()\r\n\r\nIn function bond_option_arp_ip_targets_set(), if newval-\u0026gt;string is an\nempty string, newval-\u0026gt;string+1 will point to the byte after the\nstring, causing an out-of-bound read.\r\n\r\nBUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418\nRead of size 1 at addr ffff8881119c4781 by task syz-executor665/8107\nCPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:364 [inline]\n print_report+0xc1/0x5e0 mm/kasan/report.c:475\n kasan_report+0xbe/0xf0 mm/kasan/report.c:588\n strlen+0x7d/0xa0 lib/string.c:418\n __fortify_strlen include/linux/fortify-string.h:210 [inline]\n in4_pton+0xa3/0x3f0 net/core/utils.c:130\n bond_option_arp_ip_targets_set+0xc2/0x910\ndrivers/net/bonding/bond_options.c:1201\n __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767\n __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792\n bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817\n bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156\n dev_attr_store+0x54/0x80 drivers/base/core.c:2366\n sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136\n kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x96a/0xd80 fs/read_write.c:584\n ksys_write+0x122/0x250 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n---[ end trace ]---\r\n\r\nFix it by adding a check of string length before using it.(CVE-2024-39487)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY\r\n\r\nWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes\nto bug_table entries, and as a result the last entry in a bug table will\nbe ignored, potentially leading to an unexpected panic(). All prior\nentries in the table will be handled correctly.\r\n\r\nThe arm64 ABI requires that struct fields of up to 8 bytes are\nnaturally-aligned, with padding added within a struct such that struct\nare suitably aligned within arrays.\r\n\r\nWhen CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:\r\n\r\n\tstruct bug_entry {\n\t\tsigned int      bug_addr_disp;\t// 4 bytes\n\t\tsigned int      file_disp;\t// 4 bytes\n\t\tunsigned short  line;\t\t// 2 bytes\n\t\tunsigned short  flags;\t\t// 2 bytes\n\t}\r\n\r\n... with 12 bytes total, requiring 4-byte alignment.\r\n\r\nWhen CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:\r\n\r\n\tstruct bug_entry {\n\t\tsigned int      bug_addr_disp;\t// 4 bytes\n\t\tunsigned short  flags;\t\t// 2 bytes\n\t\t\u0026lt; implicit padding \u0026gt;\t\t// 2 bytes\n\t}\r\n\r\n... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing\npadding, requiring 4-byte alginment.\r\n\r\nWhen we create a bug_entry in assembly, we align the start of the entry\nto 4 bytes, which implicitly handles padding for any prior entries.\nHowever, we do not align the end of the entry, and so when\nCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding\nbytes.\r\n\r\nFor the main kernel image this is not a problem as find_bug() doesn\u0026apos;t\ndepend on the trailing padding bytes when searching for entries:\r\n\r\n\tfor (bug = __start___bug_table; bug \u0026lt; __stop___bug_table; ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\treturn bug;\r\n\r\nHowever for modules, module_bug_finalize() depends on the trailing\nbytes when calculating the number of entries:\r\n\r\n\tmod-\u0026gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);\r\n\r\n... and as the last bug_entry lacks the necessary padding bytes, this entry\nwill not be counted, e.g. in the case of a single entry:\r\n\r\n\tsechdrs[i].sh_size == 6\n\tsizeof(struct bug_entry) == 8;\r\n\r\n\tsechdrs[i].sh_size / sizeof(struct bug_entry) == 0;\r\n\r\nConsequently module_find_bug() will miss the last bug_entry when it does:\r\n\r\n\tfor (i = 0; i \u0026lt; mod-\u0026gt;num_bugs; ++i, ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\tgoto out;\r\n\r\n... which can lead to a kenrel panic due to an unhandled bug.\r\n\r\nThis can be demonstrated with the following module:\r\n\r\n\tstatic int __init buginit(void)\n\t{\n\t\tWARN(1, \u0026quot;hello\\n\u0026quot;);\n\t\treturn 0;\n\t}\r\n\r\n\tstatic void __exit bugexit(void)\n\t{\n\t}\r\n\r\n\tmodule_init(buginit);\n\tmodule_exit(bugexit);\n\tMODULE_LICENSE(\u0026quot;GPL\u0026quot;);\r\n\r\n... which will trigger a kernel panic when loaded:\r\n\r\n\t------------[ cut here ]------------\n\thello\n\tUnexpected kernel BRK exception at EL1\n\tInternal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP\n\tModules linked in: hello(O+)\n\tCPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8\n\tHardware name: linux,dummy-virt (DT)\n\tpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n\tpc : buginit+0x18/0x1000 [hello]\n\tlr : buginit+0x18/0x1000 [hello]\n\tsp : ffff800080533ae0\n\tx29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000\n\tx26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58\n\tx23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0\n\tx20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006\n\tx17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720\n\tx14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312\n\tx11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8\n\tx8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000\n\tx5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000\n\tx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0\n\tCall trace:\n\t buginit+0x18/0x1000 [hello]\n\t do_one_initcall+0x80/0x1c8\n\t do_init_module+0x60/0x218\n\t load_module+0x1ba4/0x1d70\n\t __do_sys_init_module+0x198/0x1d0\n\t __arm64_sys_init_module+0x1c/0x28\n\t invoke_syscall+0x48/0x114\n\t el0_svc\n---truncated---(CVE-2024-39488)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix memleak in seg6_hmac_init_algo\r\n\r\nseg6_hmac_init_algo returns without cleaning up the previous allocations\nif one fails, so it\u0026apos;s going to leak all that memory and the crypto tfms.\r\n\r\nUpdate seg6_hmac_exit to only free the memory when allocated, so we can\nreuse the code directly.(CVE-2024-39489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsock_map: avoid race between sock_map_close and sk_psock_put\r\n\r\nsk_psock_get will return NULL if the refcount of psock has gone to 0, which\nwill happen when the last call of sk_psock_put is done. However,\nsk_psock_drop may not have finished yet, so the close callback will still\npoint to sock_map_close despite psock being NULL.\r\n\r\nThis can be reproduced with a thread deleting an element from the sock map,\nwhile the second one creates a socket, adds it to the map and closes it.\r\n\r\nThat will trigger the WARN_ON_ONCE:\r\n\r\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nModules linked in:\nCPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nCode: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 \u0026lt;0f\u0026gt; 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02\nRSP: 0018:ffffc9000441fda8 EFLAGS: 00010293\nRAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000\nRDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0\nRBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3\nR10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840\nR13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870\nFS:  000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n unix_release+0x87/0xc0 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0xbe/0x240 net/socket.c:1421\n __fput+0x42b/0x8a0 fs/file_table.c:422\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close fs/open.c:1541 [inline]\n __x64_sys_close+0x7f/0x110 fs/open.c:1541\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fb37d618070\nCode: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c\nRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003\nRAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070\nRDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\r\n\r\nUse sk_psock, which will only check that the pointer is not been set to\nNULL yet, which should only happen after the callbacks are restored. If,\nthen, a reference can still be gotten, we may call sk_psock_stop and cancel\npsock-\u0026gt;work.\r\n\r\nAs suggested by Paolo Abeni, reorder the condition so the control flow is\nless convoluted.\r\n\r\nAfter that change, the reproducer does not trigger the WARN_ON_ONCE\nanymore.(CVE-2024-39500)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nionic: fix use after netif_napi_del()\r\n\r\nWhen queues are started, netif_napi_add() and napi_enable() are called.\nIf there are 4 queues and only 3 queues are used for the current\nconfiguration, only 3 queues\u0026apos; napi should be registered and enabled.\nThe ionic_qcq_enable() checks whether the .poll pointer is not NULL for\nenabling only the using queue\u0026apos; napi. Unused queues\u0026apos; napi will not be\nregistered by netif_napi_add(), so the .poll pointer indicates NULL.\nBut it couldn\u0026apos;t distinguish whether the napi was unregistered or not\nbecause netif_napi_del() doesn\u0026apos;t reset the .poll pointer to NULL.\nSo, ionic_qcq_enable() calls napi_enable() for the queue, which was\nunregistered by netif_napi_del().\r\n\r\nReproducer:\n   ethtool -L \u0026lt;interface name\u0026gt; rx 1 tx 1 combined 0\n   ethtool -L \u0026lt;interface name\u0026gt; rx 0 tx 0 combined 1\n   ethtool -L \u0026lt;interface name\u0026gt; rx 0 tx 0 combined 4\r\n\r\nSplat looks like:\nkernel BUG at net/core/dev.c:6666!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16\nWorkqueue: events ionic_lif_deferred_work [ionic]\nRIP: 0010:napi_enable+0x3b/0x40\nCode: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f\nRSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029\nRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28\nRBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001\nR10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000\nR13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20\nFS:  0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die+0x33/0x90\n ? do_trap+0xd9/0x100\n ? napi_enable+0x3b/0x40\n ? do_error_trap+0x83/0xb0\n ? napi_enable+0x3b/0x40\n ? napi_enable+0x3b/0x40\n ? exc_invalid_op+0x4e/0x70\n ? napi_enable+0x3b/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? napi_enable+0x3b/0x40\n ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\n ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\n ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\n ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\n process_one_work+0x145/0x360\n worker_thread+0x2bb/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xcc/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30(CVE-2024-39502)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix possible race in __fib6_drop_pcpu_from()\r\n\r\nsyzbot found a race in __fib6_drop_pcpu_from() [1]\r\n\r\nIf compiler reads more than once (*ppcpu_rt),\nsecond read could read NULL, if another cpu clears\nthe value in rt6_get_pcpu_route().\r\n\r\nAdd a READ_ONCE() to prevent this race.\r\n\r\nAlso add rcu_read_lock()/rcu_read_unlock() because\nwe rely on RCU protection while dereferencing pcpu_rt.\r\n\r\n[1]\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]\nCPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: netns cleanup_net\n RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984\nCode: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 \u0026lt;80\u0026gt; 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48\nRSP: 0018:ffffc900040df070 EFLAGS: 00010206\nRAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16\nRDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091\nRBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007\nR10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8\nR13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001\nFS:  0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]\n  fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]\n  fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038\n  fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]\n  fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043\n  fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205\n  fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127\n  fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175\n  fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255\n  __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271\n  rt6_sync_down_dev net/ipv6/route.c:4906 [inline]\n  rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911\n  addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855\n  addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778\n  notifier_call_chain+0xb9/0x410 kernel/notifier.c:93\n  call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992\n  call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]\n  call_netdevice_notifiers net/core/dev.c:2044 [inline]\n  dev_close_many+0x333/0x6a0 net/core/dev.c:1585\n  unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193\n  unregister_netdevice_many net/core/dev.c:11276 [inline]\n  default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759\n  ops_exit_list+0x128/0x180 net/core/net_namespace.c:178\n  cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n  process_scheduled_works kernel/workqueue.c:3312 [inline]\n  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n  kthread+0x2c1/0x3a0 kernel/kthread.c:389\n  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: ensure snd_una is properly initialized on connect\r\n\r\nThis is strictly related to commit fb7a0d334894 (\u0026quot;mptcp: ensure snd_nxt\nis properly initialized on connect\u0026quot;). It turns out that syzkaller can\ntrigger the retransmit after fallback and before processing any other\nincoming packet - so that snd_una is still left uninitialized.\r\n\r\nAddress the issue explicitly initializing snd_una together with snd_nxt\nand write_seq.(CVE-2024-40931)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()\r\n\r\nFix a memory leak on logi_dj_recv_send_report() error path.(CVE-2024-40934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()\r\n\r\nThe cs35l41_hda_unbind() function clears the hda_component entry\nmatching it\u0026apos;s index and then dereferences the codec pointer held in the\nfirst element of the hda_component array, this is an issue when the\ndevice index was 0.\r\n\r\nInstead use the codec pointer stashed in the cs35l41_hda structure as it\nwill still be valid.(CVE-2024-40964)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: remove clear SB_INLINECRYPT flag in default_options\r\n\r\nIn f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.\nIf create new file or open file during this gap, these files\nwill not use inlinecrypt. Worse case, it may lead to data\ncorruption if wrappedkey_v0 is enable.\r\n\r\nThread A:                               Thread B:\r\n\r\n-f2fs_remount\t\t\t\t-f2fs_file_open or f2fs_new_inode\n  -default_options\n\t\u0026lt;- clear SB_INLINECRYPT flag\r\n\r\n                                          -fscrypt_select_encryption_impl\r\n\r\n  -parse_options\n\t\u0026lt;- set SB_INLINECRYPT again(CVE-2024-40971)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpufreq: amd-pstate: fix memory leak on CPU EPP exit\r\n\r\nThe cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is\nnot freed in the analogous exit function, so fix that.\r\n\r\n[ rjw: Subject and changelog edits ](CVE-2024-40997)",
  "id": "OESA-2024-1863",
  "modified": "2026-08-06T11:07:19Z",
  "published": "2024-07-19T11:07:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1863"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36017"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36478"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36481"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36929"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36931"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36951"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38384"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38558"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38570"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38581"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38583"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38586"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38614"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38620"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38632"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38661"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39462"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39464"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39478"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39479"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39480"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39487"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39488"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39489"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39500"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39502"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40905"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40931"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40964"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40971"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40997"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-36017",
    "CVE-2024-36478",
    "CVE-2024-36481",
    "CVE-2024-36924",
    "CVE-2024-36929",
    "CVE-2024-36931",
    "CVE-2024-36951",
    "CVE-2024-38384",
    "CVE-2024-38558",
    "CVE-2024-38570",
    "CVE-2024-38581",
    "CVE-2024-38583",
    "CVE-2024-38586",
    "CVE-2024-38614",
    "CVE-2024-38620",
    "CVE-2024-38632",
    "CVE-2024-38661",
    "CVE-2024-39462",
    "CVE-2024-39464",
    "CVE-2024-39478",
    "CVE-2024-39479",
    "CVE-2024-39480",
    "CVE-2024-39487",
    "CVE-2024-39488",
    "CVE-2024-39489",
    "CVE-2024-39500",
    "CVE-2024-39502",
    "CVE-2024-40905",
    "CVE-2024-40931",
    "CVE-2024-40934",
    "CVE-2024-40964",
    "CVE-2024-40971",
    "CVE-2024-40997"
  ]
}

RHSA-2024:4583

Vulnerability from csaf_redhat - Published: 2024-07-17 01:06 - Updated: 2026-11-10 22:24

Summary

Red Hat Security Advisory: kernel security update

Severity

Important

Scope

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

CVE-2024-38586

in linux kernel r8169, when transmitting small fragmented packets, invalid entries were inserted into the transmit ring buffer, leading to calls to dma_unmap_single() with a null address.

4.1 (Medium)


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

Fixed: 279 products

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

Open the full advisory

RHSA-2024:5364

Vulnerability from csaf_redhat - Published: 2024-08-14 01:27 - Updated: 2026-11-09 21:19

Summary

Red Hat Security Advisory: kernel security update

Severity

Important

Scope

23 vulnerabilities in this advisory, including CVE-2024-38586.

CVE-2024-38586

in linux kernel r8169, when transmitting small fragmented packets, invalid entries were inserted into the transmit ring buffer, leading to calls to dma_unmap_single() with a null address.

4.1 (Medium)


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

Fixed: 201 products

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

Open the full advisory

RHSA-2024:5365

Vulnerability from csaf_redhat - Published: 2024-08-14 01:27 - Updated: 2026-11-09 21:19

Summary

Red Hat Security Advisory: kernel-rt security update

Severity

Important

Scope

23 vulnerabilities in this advisory, including CVE-2024-38586.

CVE-2024-38586

in linux kernel r8169, when transmitting small fragmented packets, invalid entries were inserted into the transmit ring buffer, leading to calls to dma_unmap_single() with a null address.

4.1 (Medium)


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

Fixed: 34 products

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

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

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

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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

Related by attack behaviour

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

Action not permitted

CVE-2024-38586 (GCVE-0-2024-38586)

FKIE_CVE-2024-38586

GHSA-6F25-FXW5-F5MV

ICSA-25-226-07

ICSA-25-226-15

OESA-2024-1860 (CVE-2021-47391)

OESA-2024-1861 (CVE-2023-52755)

OESA-2024-1863 (CVE-2024-36017)

RHSA-2024:4583

RHSA-2024:5364

RHSA-2024:5365

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour