{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/netfilter/nf_conntrack_netlink.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "66e7650dbbb8e236e781c670b167edc81e771450",
              "status": "affected",
              "version": "7b115755fb9d3aff0ddcd18a5c4d83381362acce",
              "versionType": "git"
            },
            {
              "lessThan": "64c0b8e64be8368617ef08dfc59a3160563a1435",
              "status": "affected",
              "version": "3c79107631db1f7fd32cf3f7368e4672004a3010",
              "versionType": "git"
            },
            {
              "lessThan": "eb4ca1a97e08ff5b920664ba292e576257e2d184",
              "status": "affected",
              "version": "3c79107631db1f7fd32cf3f7368e4672004a3010",
              "versionType": "git"
            },
            {
              "lessThan": "5e2c24f7b0911b15c29aefce760bcf770542fb61",
              "status": "affected",
              "version": "3c79107631db1f7fd32cf3f7368e4672004a3010",
              "versionType": "git"
            },
            {
              "lessThan": "24f407042cf90b0872de667460230d8d50c06c39",
              "status": "affected",
              "version": "3c79107631db1f7fd32cf3f7368e4672004a3010",
              "versionType": "git"
            },
            {
              "lessThan": "27662b46f2adaa52c1665a82af4b21c42c4337fd",
              "status": "affected",
              "version": "3c79107631db1f7fd32cf3f7368e4672004a3010",
              "versionType": "git"
            },
            {
              "lessThan": "74de442b8e12a207c07953ee068009a7701aff8f",
              "status": "affected",
              "version": "3c79107631db1f7fd32cf3f7368e4672004a3010",
              "versionType": "git"
            },
            {
              "lessThan": "782161895eb4ac45cf7cfa8db375bd4766cb8299",
              "status": "affected",
              "version": "3c79107631db1f7fd32cf3f7368e4672004a3010",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "3d8b3d0384f709126beef6b917b7e97c23f18e74",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "36bbd861a402a8c5bd8f0365a5967d34cc492f09",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "1922476beeeea46bebbe577215078736dd4231dc",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "f862c13c3c926d3008b2c2bcc746ab813108dfbf",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "b0a90cae081d7ee14eaa46524fb70f4e23ae8905",
              "versionType": "git"
            },
            {
              "lessThan": "4.19.320",
              "status": "affected",
              "version": "4.19.44",
              "versionType": "semver"
            },
            {
              "lessThan": "3.17",
              "status": "affected",
              "version": "3.16.72",
              "versionType": "semver"
            },
            {
              "lessThan": "4.5",
              "status": "affected",
              "version": "4.4.191",
              "versionType": "semver"
            },
            {
              "lessThan": "4.10",
              "status": "affected",
              "version": "4.9.190",
              "versionType": "semver"
            },
            {
              "lessThan": "4.15",
              "status": "affected",
              "version": "4.14.120",
              "versionType": "semver"
            },
            {
              "lessThan": "5.1",
              "status": "affected",
              "version": "5.0.17",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/netfilter/nf_conntrack_netlink.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.1"
            },
            {
              "lessThan": "5.1",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.320",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.282",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.224",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.165",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.103",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.44",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.10.*",
              "status": "unaffected",
              "version": "6.10.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.11",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "affectedData": [
        {
          "defaultStatus": "unknown",
          "product": "RUGGEDCOM RST2428P",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "V3.1",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "RUGGEDCOM RST2428P",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 family",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 family",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SCALANCE XCM-/XRM-/XCH-/XRH-300 family",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "V3.1",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SCALANCE XCM-/XRM-/XCH-/XRH-300 family",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "*",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "V3.1.5",
              "status": "affected",
              "version": "V3.1.0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "V3.1.5",
              "status": "affected",
              "version": "V3.1.0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "V3.1.5",
              "status": "affected",
              "version": "V3.1.0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "V3.1.5",
              "status": "affected",
              "version": "V3.1.0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unknown",
          "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
          "vendor": "Siemens",
          "versions": [
            {
              "lessThan": "V3.1.5",
              "status": "affected",
              "version": "V3.1.0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "E51BE530-4BC0-4DAA-B144-7141C5472612",
              "versionEndExcluding": "5.4.282",
              "versionStartIncluding": "5.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "5CCEDF13-293D-4E64-B501-4409D0365AFE",
              "versionEndExcluding": "5.10.224",
              "versionStartIncluding": "5.5",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "B4E2B568-3171-41DE-B519-F2B1A3600D94",
              "versionEndExcluding": "5.15.165",
              "versionStartIncluding": "5.11",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "E45EAC72-8329-4F99-8276-86AF9BB3496A",
              "versionEndExcluding": "6.1.103",
              "versionStartIncluding": "5.16",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "CC912330-6B41-4C6B-99AF-F3857FBACB6A",
              "versionEndExcluding": "6.6.44",
              "versionStartIncluding": "6.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "92D388F2-1EAF-4CFA-AC06-5B26D762EA7D",
              "versionEndExcluding": "6.10.3",
              "versionStartIncluding": "6.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:4.19.320:*:*:*:*:*:*:*",
              "matchCriteriaId": "05069577-131E-4BED-A060-A8AA4A8ED542",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:5.1:*:*:*:*:*:*:*",
              "matchCriteriaId": "B3675F1D-512E-4507-A2CA-1A29D213E6D4",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: use helper function to calculate expect ID\n\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: ctnetlink: usar la funci\u00f3n auxiliar para calcular el ID de expectativa. Al eliminar la ruta de expectativa falta una llamada a la funci\u00f3n auxiliar nf_expect_get_id() para calcular el ID de expectativa; de lo contrario, el LSB de la direcci\u00f3n del objeto de expectativa se filtra al espacio de usuario."
    }
  ],
  "id": "CVE-2024-44944",
  "lastModified": "2026-06-17T07:53:16.687",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2024-44944",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2024-09-10T15:27:16.326567Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-08-30T08:15:04.580",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/24f407042cf90b0872de667460230d8d50c06c39"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/27662b46f2adaa52c1665a82af4b21c42c4337fd"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/5e2c24f7b0911b15c29aefce760bcf770542fb61"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/64c0b8e64be8368617ef08dfc59a3160563a1435"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/66e7650dbbb8e236e781c670b167edc81e771450"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/74de442b8e12a207c07953ee068009a7701aff8f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/782161895eb4ac45cf7cfa8db375bd4766cb8299"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/eb4ca1a97e08ff5b920664ba292e576257e2d184"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1182/"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    },
    {
      "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
    },
    {
      "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-401"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-44944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-30T08:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: use helper function to calculate expect ID\n\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.",
  "id": "GHSA-xq7r-x85c-27jm",
  "modified": "2026-05-12T12:32:06Z",
  "published": "2024-08-30T09:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/24f407042cf90b0872de667460230d8d50c06c39"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/27662b46f2adaa52c1665a82af4b21c42c4337fd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5e2c24f7b0911b15c29aefce760bcf770542fb61"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/64c0b8e64be8368617ef08dfc59a3160563a1435"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/66e7650dbbb8e236e781c670b167edc81e771450"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/74de442b8e12a207c07953ee068009a7701aff8f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/782161895eb4ac45cf7cfa8db375bd4766cb8299"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eb4ca1a97e08ff5b920664ba292e576257e2d184"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1182"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.92.0.173.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.92.0.173.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.92.0.173.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\nibmvnic: don\u0026apos;t release napi in __ibmvnic_open()\r\n\r\nIf __ibmvnic_open() encounters an error such as when setting link state,\nit calls release_resources() which frees the napi structures needlessly.\nInstead, have __ibmvnic_open() only clean up the work it did so far (i.e.\ndisable napi and irqs) and leave the rest to the callers.\r\n\r\nIf caller of __ibmvnic_open() is ibmvnic_open(), it should release the\nresources immediately. If the caller is do_reset() or do_hard_reset(),\nthey will release the resources on the next reset.\r\n\r\nThis fixes following crash that occurred when running the drmgr command\nseveral times to add/remove a vnic interface:\r\n\r\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq\n\t[102056] ibmvnic 30000003 env3: Replenished 8 pools\n\tKernel attempted to read user page (10) - exploit attempt? (uid: 0)\n\tBUG: Kernel NULL pointer dereference on read at 0x00000010\n\tFaulting instruction address: 0xc000000000a3c840\n\tOops: Kernel access of bad area, sig: 11 [#1]\n\tLE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n\t...\n\tCPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1\n\tWorkqueue: events_long __ibmvnic_reset [ibmvnic]\n\tNIP:  c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820\n\tREGS: c0000000548e37e0 TRAP: 0300   Not tainted  (5.16.0-rc5-autotest-g6441998e2e37)\n\tMSR:  8000000000009033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt;  CR: 28248484  XER: 00000004\n\tCFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0\n\tGPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000\n\t...\n\tNIP [c000000000a3c840] napi_enable+0x20/0xc0\n\tLR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]\n\tCall Trace:\n\t[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)\n\t[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]\n\t[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]\n\t[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570\n\t[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660\n\t[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0\n\t[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64\n\tInstruction dump:\n\t7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010\n\t38a0fff6 e92d1100 f9210028 39200000 \u0026lt;e9030010\u0026gt; f9010020 60420000 e9210020\n\t---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer\r\n\r\nDriver\u0026apos;s probe allocates memory for RX FIFO (port-\u0026gt;rx_fifo) based on\ndefault RX FIFO depth, e.g. 16.  Later during serial startup the\nqcom_geni_serial_port_setup() updates the RX FIFO depth\n(port-\u0026gt;rx_fifo_depth) to match real device capabilities, e.g. to 32.\r\n\r\nThe RX UART handle code will read \u0026quot;port-\u0026gt;rx_fifo_depth\u0026quot; number of words\ninto \u0026quot;port-\u0026gt;rx_fifo\u0026quot; buffer, thus exceeding the bounds.  This can be\nobserved in certain configurations with Qualcomm Bluetooth HCI UART\ndevice and KASAN:\r\n\r\n  Bluetooth: hci0: QCA Product ID   :0x00000010\n  Bluetooth: hci0: QCA SOC Version  :0x400a0200\n  Bluetooth: hci0: QCA ROM Version  :0x00000200\n  Bluetooth: hci0: QCA Patch Version:0x00000d2b\n  Bluetooth: hci0: QCA controller version 0x02000200\n  Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv\n  bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2\n  Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)\n  Bluetooth: hci0: QCA Failed to download patch (-2)\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c\n  Write of size 4 at addr ffff279347d578c0 by task swapper/0/0\r\n\r\n  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26\n  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)\n  Call trace:\n   dump_backtrace.part.0+0xe0/0xf0\n   show_stack+0x18/0x40\n   dump_stack_lvl+0x8c/0xb8\n   print_report+0x188/0x488\n   kasan_report+0xb4/0x100\n   __asan_store4+0x80/0xa4\n   handle_rx_uart+0xa8/0x18c\n   qcom_geni_serial_handle_rx+0x84/0x9c\n   qcom_geni_serial_isr+0x24c/0x760\n   __handle_irq_event_percpu+0x108/0x500\n   handle_irq_event+0x6c/0x110\n   handle_fasteoi_irq+0x138/0x2cc\n   generic_handle_domain_irq+0x48/0x64\r\n\r\nIf the RX FIFO depth changes after probe, be sure to resize the buffer.(CVE-2022-48871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: sdata can be NULL during AMPDU start\r\n\r\nieee80211_tx_ba_session_handle_start() may get NULL for sdata when a\ndeauthentication is ongoing.\r\n\r\nHere a trace triggering the race with the hostapd test\nmulti_ap_fronthaul_on_ap:\r\n\r\n(gdb) list *drv_ampdu_action+0x46\n0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).\n391             int ret = -EOPNOTSUPP;\n392\n393             might_sleep();\n394\n395             sdata = get_bss_sdata(sdata);\n396             if (!check_sdata_in_driver(sdata))\n397                     return -EIO;\n398\n399             trace_drv_ampdu_action(local, sdata, params);\n400\r\n\r\nwlan0: moving STA 02:00:00:00:03:00 to state 3\nwlan0: associated\nwlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)\nwlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0\nwlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)\nwlan0: moving STA 02:00:00:00:03:00 to state 2\nwlan0: moving STA 02:00:00:00:03:00 to state 1\nwlan0: Removed STA 02:00:00:00:03:00\nwlan0: Destroyed STA 02:00:00:00:03:00\nBUG: unable to handle page fault for address: fffffffffffffb48\nPGD 11814067 P4D 11814067 PUD 11816067 PMD 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G        W          6.1.0-rc8-wt+ #59\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014\nWorkqueue: phy3 ieee80211_ba_session_work [mac80211]\nRIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]\nCode: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 \u0026lt;8b\u0026gt; 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85\nRSP: 0018:ffffc900025ebd20 EFLAGS: 00010287\nRAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240\nRDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40\nRBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001\nR10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0\nR13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8\nFS:  0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]\n ieee80211_ba_session_work+0xff/0x2e0 [mac80211]\n process_one_work+0x29f/0x620\n worker_thread+0x4d/0x3d0\n ? process_one_work+0x620/0x620\n kthread+0xfb/0x120\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x22/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2022-48875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: let\u0026apos;s avoid panic if extent_tree is not created\r\n\r\nThis patch avoids the below panic.\r\n\r\npc : __lookup_extent_tree+0xd8/0x760\nlr : f2fs_do_write_data_page+0x104/0x87c\nsp : ffffffc010cbb3c0\nx29: ffffffc010cbb3e0 x28: 0000000000000000\nx27: ffffff8803e7f020 x26: ffffff8803e7ed40\nx25: ffffff8803e7f020 x24: ffffffc010cbb460\nx23: ffffffc010cbb480 x22: 0000000000000000\nx21: 0000000000000000 x20: ffffffff22e90900\nx19: 0000000000000000 x18: ffffffc010c5d080\nx17: 0000000000000000 x16: 0000000000000020\nx15: ffffffdb1acdbb88 x14: ffffff888759e2b0\nx13: 0000000000000000 x12: ffffff802da49000\nx11: 000000000a001200 x10: ffffff8803e7ed40\nx9 : ffffff8023195800 x8 : ffffff802da49078\nx7 : 0000000000000001 x6 : 0000000000000000\nx5 : 0000000000000006 x4 : ffffffc010cbba28\nx3 : 0000000000000000 x2 : ffffffc010cbb480\nx1 : 0000000000000000 x0 : ffffff8803e7ed40\nCall trace:\n __lookup_extent_tree+0xd8/0x760\n f2fs_do_write_data_page+0x104/0x87c\n f2fs_write_single_data_page+0x420/0xb60\n f2fs_write_cache_pages+0x418/0xb1c\n __f2fs_write_data_pages+0x428/0x58c\n f2fs_write_data_pages+0x30/0x40\n do_writepages+0x88/0x190\n __writeback_single_inode+0x48/0x448\n writeback_sb_inodes+0x468/0x9e8\n __writeback_inodes_wb+0xb8/0x2a4\n wb_writeback+0x33c/0x740\n wb_do_writeback+0x2b4/0x400\n wb_workfn+0xe4/0x34c\n process_one_work+0x24c/0x5bc\n worker_thread+0x3e8/0xa50\n kthread+0x150/0x1b4(CVE-2022-48877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nregulator: da9211: Use irq handler when ready\r\n\r\nIf the system does not come from reset (like when it is kexec()), the\nregulator might have an IRQ waiting for us.\r\n\r\nIf we enable the IRQ handler before its structures are ready, we crash.\r\n\r\nThis patch fixes:\r\n\r\n[    1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078\n[    1.316096] Call trace:\n[    1.316101]  blocking_notifier_call_chain+0x20/0xa8\n[    1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests\n[    1.327823]  regulator_notifier_call_chain+0x1c/0x2c\n[    1.327825]  da9211_irq_handler+0x68/0xf8\n[    1.327829]  irq_thread+0x11c/0x234\n[    1.327833]  kthread+0x13c/0x154(CVE-2022-48891)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: Fix null pointer deref when receiving skb during sock creation\r\n\r\nThe panic below is observed when receiving ICMP packets with secmark set\nwhile an ICMP raw socket is being created. SK_CTX(sk)-\u0026gt;label is updated\nin apparmor_socket_post_create(), but the packet is delivered to the\nsocket before that, causing the null pointer dereference.\nDrop the packet if label context is not set.\r\n\r\n    BUG: kernel NULL pointer dereference, address: 000000000000004c\n    #PF: supervisor read access in kernel mode\n    #PF: error_code(0x0000) - not-present page\n    PGD 0 P4D 0\n    Oops: 0000 [#1] PREEMPT SMP NOPTI\n    CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df\n    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020\n    RIP: 0010:aa_label_next_confined+0xb/0x40\n    Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 \u0026lt;8b\u0026gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2\n    RSP: 0018:ffffa92940003b08 EFLAGS: 00010246\n    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e\n    RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000\n    RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002\n    R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400\n    R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000\n    FS:  00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0\n    PKRU: 55555554\n    Call Trace:\n     \u0026lt;IRQ\u0026gt;\n     ? __die+0x23/0x70\n     ? page_fault_oops+0x171/0x4e0\n     ? exc_page_fault+0x7f/0x180\n     ? asm_exc_page_fault+0x26/0x30\n     ? aa_label_next_confined+0xb/0x40\n     apparmor_secmark_check+0xec/0x330\n     security_sock_rcv_skb+0x35/0x50\n     sk_filter_trim_cap+0x47/0x250\n     sock_queue_rcv_skb_reason+0x20/0x60\n     raw_rcv+0x13c/0x210\n     raw_local_deliver+0x1f3/0x250\n     ip_protocol_deliver_rcu+0x4f/0x2f0\n     ip_local_deliver_finish+0x76/0xa0\n     __netif_receive_skb_one_core+0x89/0xa0\n     netif_receive_skb+0x119/0x170\n     ? __netdev_alloc_skb+0x3d/0x140\n     vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n     vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n     __napi_poll+0x28/0x1b0\n     net_rx_action+0x2a4/0x380\n     __do_softirq+0xd1/0x2c8\n     __irq_exit_rcu+0xbb/0xf0\n     common_interrupt+0x86/0xa0\n     \u0026lt;/IRQ\u0026gt;\n     \u0026lt;TASK\u0026gt;\n     asm_common_interrupt+0x26/0x40\n    RIP: 0010:apparmor_socket_post_create+0xb/0x200\n    Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 \u0026lt;55\u0026gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48\n    RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286\n    RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001\n    RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740\n    RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\n    R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003\n    R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748\n     ? __pfx_apparmor_socket_post_create+0x10/0x10\n     security_socket_post_create+0x4b/0x80\n     __sock_create+0x176/0x1f0\n     __sys_socket+0x89/0x100\n     __x64_sys_socket+0x17/0x20\n     do_syscall_64+0x5d/0x90\n     ? do_syscall_64+0x6c/0x90\n     ? do_syscall_64+0x6c/0x90\n     ? do_syscall_64+0x6c/0x90\n     entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix race between quota rescan and disable leading to NULL pointer deref\r\n\r\nIf we have one task trying to start the quota rescan worker while another\none is trying to disable quotas, we can end up hitting a race that results\nin the quota rescan worker doing a NULL pointer dereference. The steps for\nthis are the following:\r\n\r\n1) Quotas are enabled;\r\n\r\n2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().\n   It calls qgroup_rescan_init() which returns 0 (success) and then joins a\n   transaction and commits it;\r\n\r\n3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().\n   It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info-\u0026gt;flags and calls\n   btrfs_qgroup_wait_for_completion(), which returns immediately since the\n   rescan worker is not yet running.\n   Then it starts a transaction and locks fs_info-\u0026gt;qgroup_ioctl_lock;\r\n\r\n4) Task A queues the rescan worker, by calling btrfs_queue_work();\r\n\r\n5) The rescan worker starts, and calls rescan_should_stop() at the start\n   of its while loop, which results in 0 iterations of the loop, since\n   the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info-\u0026gt;flags by\n   task B at step 3);\r\n\r\n6) Task B sets fs_info-\u0026gt;quota_root to NULL;\r\n\r\n7) The rescan worker tries to start a transaction and uses\n   fs_info-\u0026gt;quota_root as the root argument for btrfs_start_transaction().\n   This results in a NULL pointer dereference down the call chain of\n   btrfs_start_transaction(). The stack trace is something like the one\n   reported in Link tag below:\r\n\r\n   general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN\n   KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]\n   CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0\n   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\n   Workqueue: btrfs-qgroup-rescan btrfs_work_helper\n   RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564\n   Code: 48 89 fb 48 (...)\n   RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206\n   RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80\n   RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\n   RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d\n   R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000\n   R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003\n   FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000\n   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n   CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0\n   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n   Call Trace:\n    \u0026lt;TASK\u0026gt;\n    btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402\n    btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280\n    process_one_work+0x877/0xdb0 kernel/workqueue.c:2289\n    worker_thread+0xb14/0x1330 kernel/workqueue.c:2436\n    kthread+0x266/0x300 kernel/kthread.c:376\n    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n    \u0026lt;/TASK\u0026gt;\n   Modules linked in:\r\n\r\nSo fix this by having the rescan worker function not attempt to start a\ntransaction if it didn\u0026apos;t do any rescan work.(CVE-2023-52896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nAdd exception protection processing for vd in axi_chan_handle_err function\r\n\r\nSince there is no protection for vd, a kernel panic will be\ntriggered here in exceptional cases.\r\n\r\nYou can refer to the processing of axi_chan_block_xfer_complete function\r\n\r\nThe triggered kernel panic is as follows:\r\n\r\n[   67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060\n[   67.848447] Mem abort info:\n[   67.848449]   ESR = 0x96000004\n[   67.848451]   EC = 0x25: DABT (current EL), IL = 32 bits\n[   67.848454]   SET = 0, FnV = 0\n[   67.848456]   EA = 0, S1PTW = 0\n[   67.848458] Data abort info:\n[   67.848460]   ISV = 0, ISS = 0x00000004\n[   67.848462]   CM = 0, WnR = 0\n[   67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000\n[   67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000\n[   67.848472] Internal error: Oops: 96000004 [#1] SMP\n[   67.848475] Modules linked in: dmatest\n[   67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11\n[   67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)\n[   67.848487] pc : axi_chan_handle_err+0xc4/0x230\n[   67.848491] lr : axi_chan_handle_err+0x30/0x230\n[   67.848493] sp : ffff0803fe55ae50\n[   67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200\n[   67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080\n[   67.848504] x25: ffff800010d33880 x24: ffff80001139d850\n[   67.848508] x23: ffff0800c097c168 x22: 0000000000000000\n[   67.848512] x21: 0000000000000080 x20: 0000000000002000\n[   67.848517] x19: ffff0800c097c080 x18: 0000000000000000\n[   67.848521] x17: 0000000000000000 x16: 0000000000000000\n[   67.848525] x15: 0000000000000000 x14: 0000000000000000\n[   67.848529] x13: 0000000000000000 x12: 0000000000000040\n[   67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a\n[   67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270\n[   67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0\n[   67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480\n[   67.848550] x3 : dead000000000100 x2 : dead000000000122\n[   67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168\n[   67.848559] Call trace:\n[   67.848562]  axi_chan_handle_err+0xc4/0x230\n[   67.848566]  dw_axi_dma_interrupt+0xf4/0x590\n[   67.848569]  __handle_irq_event_percpu+0x60/0x220\n[   67.848573]  handle_irq_event+0x64/0x120\n[   67.848576]  handle_fasteoi_irq+0xc4/0x220\n[   67.848580]  __handle_domain_irq+0x80/0xe0\n[   67.848583]  gic_handle_irq+0xc0/0x138\n[   67.848585]  el1_irq+0xc8/0x180\n[   67.848588]  arch_cpu_idle+0x14/0x2c\n[   67.848591]  default_idle_call+0x40/0x16c\n[   67.848594]  do_idle+0x1f0/0x250\n[   67.848597]  cpu_startup_entry+0x2c/0x60\n[   67.848600]  rest_init+0xc0/0xcc\n[   67.848603]  arch_call_rest_init+0x14/0x1c\n[   67.848606]  start_kernel+0x4cc/0x500\n[   67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)\n[   67.848613] ---[ end trace 585a97036f88203a ]---(CVE-2023-52899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_mpls: Fix warning during failed attribute validation\r\n\r\nThe \u0026apos;TCA_MPLS_LABEL\u0026apos; attribute is of \u0026apos;NLA_U32\u0026apos; type, but has a\nvalidation type of \u0026apos;NLA_VALIDATE_FUNCTION\u0026apos;. This is an invalid\ncombination according to the comment above \u0026apos;struct nla_policy\u0026apos;:\r\n\r\n\u0026quot;\nMeaning of `validate\u0026apos; field, use via NLA_POLICY_VALIDATE_FN:\n   NLA_BINARY           Validation function called for the attribute.\n   All other            Unused - but note that it\u0026apos;s a union\n\u0026quot;\r\n\r\nThis can trigger the warning [1] in nla_get_range_unsigned() when\nvalidation of the attribute fails. Despite being of \u0026apos;NLA_U32\u0026apos; type, the\nassociated \u0026apos;min\u0026apos;/\u0026apos;max\u0026apos; fields in the policy are negative as they are\naliased by the \u0026apos;validate\u0026apos; field.\r\n\r\nFix by changing the attribute type to \u0026apos;NLA_BINARY\u0026apos; which is consistent\nwith the above comment and all other users of NLA_POLICY_VALIDATE_FN().\nAs a result, move the length validation to the validation function.\r\n\r\nNo regressions in MPLS tests:\r\n\r\n # ./tdc.py -f tc-tests/actions/mpls.json\n [...]\n # echo $?\n 0\r\n\r\n[1]\nWARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118\nnla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117\nModules linked in:\nCPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014\nRIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310\n netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411\n netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]\n netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506\n netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546\n rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg net/socket.c:734 [inline]\n ____sys_sendmsg+0x38f/0x500 net/socket.c:2482\n ___sys_sendmsg net/socket.c:2536 [inline]\n __sys_sendmsg+0x197/0x230 net/socket.c:2565\n __do_sys_sendmsg net/socket.c:2574 [inline]\n __se_sys_sendmsg net/socket.c:2572 [inline]\n __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-52906)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory\r\n\r\nThere is a potential out-of-bounds access when using test_bit() on a single\nword. The test_bit() and set_bit() functions operate on long values, and\nwhen testing or setting a single word, they can exceed the word\nboundary. KASAN detects this issue and produces a dump:\r\n\r\n\t BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas\r\n\r\n\t Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965\r\n\r\nFor full log, please look at [1].\r\n\r\nMake the allocation at least the size of sizeof(unsigned long) so that\nset_bit() and test_bit() have sufficient room for read/write operations\nwithout overwriting unallocated memory.\r\n\r\n[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: change vm-\u0026gt;task_info handling\r\n\r\nThis patch changes the handling and lifecycle of vm-\u0026gt;task_info object.\nThe major changes are:\n- vm-\u0026gt;task_info is a dynamically allocated ptr now, and its uasge is\n  reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n    - amdgpu_vm_get_task_info: reference counts up task_info before\n      returning this info\n    - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\r\n\r\nThis patch also does logistical changes required for existing usage\nof vm-\u0026gt;task_info.\r\n\r\nV2: Do not block all the prints when task_info not found (Felix)\r\n\r\nV3: Fixed review comments from Felix\n   - Fix wrong indentation\n   - No debug message for -ENOMEM\n   - Add NULL check for task_info\n   - Do not duplicate the debug messages (ti vs no ti)\n   - Get first reference of task_info in vm_init(), put last\n     in vm_fini()\r\n\r\nV4: Fixed review comments from Felix\n   - fix double reference increment in create_task_info\n   - change amdgpu_vm_get_task_info_pasid\n   - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()\r\n\r\nxattr in ocfs2 maybe \u0026apos;non-indexed\u0026apos;, which saved with additional space\nrequested.  It\u0026apos;s better to check if the memory is out of bound before\nmemcmp, although this possibility mainly comes from crafted poisonous\nimages.(CVE-2024-41016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: check bo_va-\u0026gt;bo is non-NULL before using it\r\n\r\nThe call to radeon_vm_clear_freed might clear bo_va-\u0026gt;bo, so\nwe have to check it before dereferencing it.(CVE-2024-41060)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-fabrics: use reserved tag for reg read/write command\r\n\r\nIn some scenarios, if too many commands are issued by nvme command in\nthe same time by user tasks, this may exhaust all tags of admin_q. If\na reset (nvme reset or IO timeout) occurs before these commands finish,\nreconnect routine may fail to update nvme regs due to insufficient tags,\nwhich will cause kernel hang forever. In order to workaround this issue,\nmaybe we can let reg_read32()/reg_read64()/reg_write32() use reserved\ntags. This maybe safe for nvmf:\r\n\r\n1. For the disable ctrl path,  we will not issue connect command\n2. For the enable ctrl / fw activate path, since connect and reg_xx()\n   are called serially.\r\n\r\nSo the reserved tags may still be enough while reg_xx() use reserved tags.(CVE-2024-41082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\r\n\r\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.(CVE-2024-42153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Fix scv instruction crash with kexec\r\n\r\nkexec on pseries disables AIL (reloc_on_exc), required for scv\ninstruction support, before other CPUs have been shut down. This means\nthey can execute scv instructions after AIL is disabled, which causes an\ninterrupt at an unexpected entry location that crashes the kernel.\r\n\r\nChange the kexec sequence to disable AIL after other CPUs have been\nbrought down.\r\n\r\nAs a refresher, the real-mode scv interrupt vector is 0x17000, and the\nfixed-location head code probably couldn\u0026apos;t easily deal with implementing\nsuch high addresses so it was just decided not to support that interrupt\nat all.(CVE-2024-42230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: validate nvme_local_port correctly\r\n\r\nThe driver load failed with error message,\r\n\r\nqla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef\r\n\r\nand with a kernel crash,\r\n\r\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000070\n\tWorkqueue: events_unbound qla_register_fcport_fn [qla2xxx]\n\tRIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]\n\tRSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282\n\tRAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000\n\tRDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000\n\tRBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030\n\tR10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4\n\tR13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8\n\tFS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000\n\tCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\tCR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0\n\tCall Trace:\n\tqla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]\n\t? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]\n\tqla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]\n\tqla_register_fcport_fn+0x54/0xc0 [qla2xxx]\r\n\r\nExit the qla_nvme_register_remote() function when qla_nvme_register_hba()\nfails and correctly validate nvme_local_port.(CVE-2024-42286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Fix for possible memory corruption\r\n\r\nInit Control Block is dereferenced incorrectly.  Correctly dereference ICB(CVE-2024-42288)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: handle inconsistent state in nilfs_btnode_create_block()\r\n\r\nSyzbot reported that a buffer state inconsistency was detected in\nnilfs_btnode_create_block(), triggering a kernel bug.\r\n\r\nIt is not appropriate to treat this inconsistency as a bug; it can occur\nif the argument block address (the buffer index of the newly created\nblock) is a virtual block number and has been reallocated due to\ncorruption of the bitmap used to manage its allocation state.\r\n\r\nSo, modify nilfs_btnode_create_block() and its callers to treat it as a\npossible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Update log-\u0026gt;page_{mask,bits} if log-\u0026gt;page_size changed\r\n\r\nIf an NTFS file system is mounted to another system with different\nPAGE_SIZE from the original system, log-\u0026gt;page_size will change in\nlog_replay(), but log-\u0026gt;page_{mask,bits} don\u0026apos;t change correspondingly.\nThis will cause a panic because \u0026quot;u32 bytes = log-\u0026gt;page_size - page_off\u0026quot;\nwill get a negative value in the later read_log_page().(CVE-2024-42299)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysctl: always initialize i_uid/i_gid\r\n\r\nAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()\ncan safely skip setting them.\r\n\r\nCommit 5ec27ec735ba (\u0026quot;fs/proc/proc_sysctl.c: fix the default values of\ni_uid/i_gid on /proc/sys inodes.\u0026quot;) added defaults for i_uid/i_gid when\nset_ownership() was not implemented. It also missed adjusting\nnet_ctl_set_ownership() to use the same default values in case the\ncomputation of a better value failed.(CVE-2024-42312)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: endpoint: pci-epf-test: Make use of cached \u0026apos;epc_features\u0026apos; in pci_epf_test_core_init()\r\n\r\nInstead of getting the epc_features from pci_epc_get_features() API, use\nthe cached pci_epf_test::epc_features value to avoid the NULL check. Since\nthe NULL check is already performed in pci_epf_test_bind(), having one more\ncheck in pci_epf_test_core_init() is redundant and it is not possible to\nhit the NULL pointer dereference.\r\n\r\nAlso with commit a01e7214bef9 (\u0026quot;PCI: endpoint: Remove \u0026quot;core_init_notifier\u0026quot;\nflag\u0026quot;), \u0026apos;epc_features\u0026apos; got dereferenced without the NULL check, leading to\nthe following false positive Smatch warning:\r\n\r\n  drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed \u0026apos;epc_features\u0026apos; could be null (see line 747)\r\n\r\nThus, remove the redundant NULL check and also use the epc_features::\n{msix_capable/msi_capable} flags directly to avoid local variables.\r\n\r\n[kwilczynski: commit log](CVE-2024-43824)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxdp: fix invalid wait context of page_pool_destroy()\r\n\r\nIf the driver uses a page pool, it creates a page pool with\npage_pool_create().\nThe reference count of page pool is 1 as default.\nA page pool will be destroyed only when a reference count reaches 0.\npage_pool_destroy() is used to destroy page pool, it decreases a\nreference count.\nWhen a page pool is destroyed, -\u0026gt;disconnect() is called, which is\nmem_allocator_disconnect().\nThis function internally acquires mutex_lock().\r\n\r\nIf the driver uses XDP, it registers a memory model with\nxdp_rxq_info_reg_mem_model().\nThe xdp_rxq_info_reg_mem_model() internally increases a page pool\nreference count if a memory model is a page pool.\nNow the reference count is 2.\r\n\r\nTo destroy a page pool, the driver should call both page_pool_destroy()\nand xdp_unreg_mem_model().\nThe xdp_unreg_mem_model() internally calls page_pool_destroy().\nOnly page_pool_destroy() decreases a reference count.\r\n\r\nIf a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we\nwill face an invalid wait context warning.\nBecause xdp_unreg_mem_model() calls page_pool_destroy() with\nrcu_read_lock().\nThe page_pool_destroy() internally acquires mutex_lock().\r\n\r\nSplat looks like:\n=============================\n[ BUG: Invalid wait context ]\n6.10.0-rc6+ #4 Tainted: G W\n-----------------------------\nethtool/1806 is trying to lock:\nffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150\nother info that might help us debug this:\ncontext-{5:5}\n3 locks held by ethtool/1806:\nstack backtrace:\nCPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x7e/0xc0\n__lock_acquire+0x1681/0x4de0\n? _printk+0x64/0xe0\n? __pfx_mark_lock.part.0+0x10/0x10\n? __pfx___lock_acquire+0x10/0x10\nlock_acquire+0x1b3/0x580\n? mem_allocator_disconnect+0x73/0x150\n? __wake_up_klogd.part.0+0x16/0xc0\n? __pfx_lock_acquire+0x10/0x10\n? dump_stack_lvl+0x91/0xc0\n__mutex_lock+0x15c/0x1690\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_prb_read_valid+0x10/0x10\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_llist_add_batch+0x10/0x10\n? console_unlock+0x193/0x1b0\n? lockdep_hardirqs_on+0xbe/0x140\n? __pfx___mutex_lock+0x10/0x10\n? tick_nohz_tick_stopped+0x16/0x90\n? __irq_work_queue_local+0x1e5/0x330\n? irq_work_queue+0x39/0x50\n? __wake_up_klogd.part.0+0x79/0xc0\n? mem_allocator_disconnect+0x73/0x150\nmem_allocator_disconnect+0x73/0x150\n? __pfx_mem_allocator_disconnect+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? rcu_is_watching+0x11/0xb0\npage_pool_release+0x36e/0x6d0\npage_pool_destroy+0xd7/0x440\nxdp_unreg_mem_model+0x1a7/0x2a0\n? __pfx_xdp_unreg_mem_model+0x10/0x10\n? kfree+0x125/0x370\n? bnxt_free_ring.isra.0+0x2eb/0x500\n? bnxt_free_mem+0x5ac/0x2500\nxdp_rxq_info_unreg+0x4a/0xd0\nbnxt_free_mem+0x1356/0x2500\nbnxt_close_nic+0xf0/0x3b0\n? __pfx_bnxt_close_nic+0x10/0x10\n? ethnl_parse_bit+0x2c6/0x6d0\n? __pfx___nla_validate_parse+0x10/0x10\n? __pfx_ethnl_parse_bit+0x10/0x10\nbnxt_set_features+0x2a8/0x3e0\n__netdev_update_features+0x4dc/0x1370\n? ethnl_parse_bitset+0x4ff/0x750\n? __pfx_ethnl_parse_bitset+0x10/0x10\n? __pfx___netdev_update_features+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? _raw_spin_unlock_irqrestore+0x42/0x70\n? __pm_runtime_resume+0x7d/0x110\nethnl_set_features+0x32d/0xa20\r\n\r\nTo fix this problem, it uses rhashtable_lookup_fast() instead of\nrhashtable_lookup() with rcu_read_lock().\nUsing xa without rcu_read_lock() here is safe.\nxa is freed by __xdp_mem_allocator_rcu_free() and this is called by\ncall_rcu() of mem_xa_remove().\nThe mem_xa_remove() is called by page_pool_destroy() if a reference\ncount reaches 0.\nThe xa is already protected by the reference count mechanism well in the\ncontrol plane.\nSo removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: initialize integrity buffer to zero before writing it to media\r\n\r\nMetadata added by bio_integrity_prep is using plain kmalloc, which leads\nto random kernel memory being written media.  For PI metadata this is\nlimited to the app tag that isn\u0026apos;t used by kernel generated metadata,\nbut for non-PI metadata the entire buffer leaks kernel memory.\r\n\r\nFix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: vhci-hcd: Do not drop references before new references are gained\r\n\r\nAt a few places the driver carries stale pointers\nto references that can still be used. Make sure that does not happen.\nThis strictly speaking closes ZDI-CAN-22273, though there may be\nsimilar races in the driver.(CVE-2024-43883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: MGMT: Add error handling to pair_device()\r\n\r\nhci_conn_params_add() never checks for a NULL value and could lead to a NULL\npointer dereference causing a crash.\r\n\r\nFixed by adding error handling in the function.(CVE-2024-43884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npadata: Fix possible divide-by-0 panic in padata_mt_helper()\r\n\r\nWe are hit with a not easily reproducible divide-by-0 panic in padata.c at\nbootup time.\r\n\r\n  [   10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI\n  [   10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1\n  [   10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021\n  [   10.017908] Workqueue: events_unbound padata_mt_helper\n  [   10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0\n    :\n  [   10.017963] Call Trace:\n  [   10.017968]  \u0026lt;TASK\u0026gt;\n  [   10.018004]  ? padata_mt_helper+0x39/0xb0\n  [   10.018084]  process_one_work+0x174/0x330\n  [   10.018093]  worker_thread+0x266/0x3a0\n  [   10.018111]  kthread+0xcf/0x100\n  [   10.018124]  ret_from_fork+0x31/0x50\n  [   10.018138]  ret_from_fork_asm+0x1a/0x30\n  [   10.018147]  \u0026lt;/TASK\u0026gt;\r\n\r\nLooking at the padata_mt_helper() function, the only way a divide-by-0\npanic can happen is when ps-\u0026gt;chunk_size is 0.  The way that chunk_size is\ninitialized in padata_do_multithreaded(), chunk_size can be 0 when the\nmin_chunk in the passed-in padata_mt_job structure is 0.\r\n\r\nFix this divide-by-0 panic by making sure that chunk_size will be at least\n1 no matter what the input parameters are.(CVE-2024-43889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Fix overflow in get_free_elt()\r\n\r\n\u0026quot;tracing_map-\u0026gt;next_elt\u0026quot; in get_free_elt() is at risk of overflowing.\r\n\r\nOnce it overflows, new elements can still be inserted into the tracing_map\neven though the maximum number of elements (`max_elts`) has been reached.\nContinuing to insert elements after the overflow could result in the\ntracing_map containing \u0026quot;tracing_map-\u0026gt;max_size\u0026quot; elements, leaving no empty\nentries.\nIf any attempt is made to insert an element into a full tracing_map using\n`__tracing_map_insert()`, it will cause an infinite loop with preemption\ndisabled, leading to a CPU hang problem.\r\n\r\nFix this by preventing any further increments to \u0026quot;tracing_map-\u0026gt;next_elt\u0026quot;\nonce it reaches \u0026quot;tracing_map-\u0026gt;max_elt\u0026quot;.(CVE-2024-43890)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: sanity check for NULL pointer after ext4_force_shutdown\r\n\r\nTest case: 2 threads write short inline data to a file.\nIn ext4_page_mkwrite the resulting inline data is converted.\nHandling ext4_grp_locked_error with description \u0026quot;block bitmap\nand bg descriptor inconsistent: X vs Y free clusters\u0026quot; calls\next4_force_shutdown. The conversion clears\nEXT4_STATE_MAY_INLINE_DATA but fails for\next4_destroy_inline_data_nolock and ext4_mark_iloc_dirty due\nto ext4_forced_shutdown. The restoration of inline data fails\nfor the same reason not setting EXT4_STATE_MAY_INLINE_DATA.\nWithout the flag set a regular process path in ext4_da_write_end\nfollows trying to dereference page folio private pointer that has\nnot been set. The fix calls early return with -EIO error shall the\npointer to private be NULL.\r\n\r\nSample crash report:\r\n\r\nUnable to handle kernel paging request at virtual address dfff800000000004\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nMem abort info:\n  ESR = 0x0000000096000005\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x05: level 1 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[dfff800000000004] address between user and kernel address ranges\nInternal error: Oops: 0000000096000005 [#1] PREEMPT SMP\nModules linked in:\nCPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\nlr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160\nsp : ffff8000a1957600\nx29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0\nx26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000\nx23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020\nx20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196\nx17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0\nx14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020\nx2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0\nCall trace:\n __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\n block_write_end+0xb4/0x104 fs/buffer.c:2253\n ext4_da_do_write_end fs/ext4/inode.c:2955 [inline]\n ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028\n generic_perform_write+0x394/0x588 mm/filemap.c:3985\n ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299\n ext4_file_write_iter+0x188/0x1780\n call_write_iter include/linux/fs.h:2110 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x968/0xc3c fs/read_write.c:590\n ksys_write+0x15c/0x26c fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __arm64_sys_write+0x7c/0x90 fs/read_write.c:652\n __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\nCode: 97f85911 f94002da 91008356 d343fec8 (38796908)\n---[ end trace 0000000000000000 ]---\n----------------\nCode disassembly (best guess):\n   0:\t97f85911 \tbl\t0xffffffffffe16444\n   4:\tf94002da \tldr\tx26, [x22]\n   8:\t91008356 \tadd\tx22, x26, #0x20\n   c:\td343fec8 \tlsr\tx8, x22, #3\n* 10:\t38796908 \tldrb\tw8, [x8, x25] \u0026lt;-- trapping instruction(CVE-2024-43898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: Fix the null pointer dereference for vega10_hwmgr\r\n\r\nCheck return value and conduct null pointer handling to avoid null pointer dereference.(CVE-2024-43905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix the null pointer dereference to ras_manager\r\n\r\nCheck ras_manager before using it(CVE-2024-43908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: mcast: wait for previous gc cycles when removing port\r\n\r\nsyzbot hit a use-after-free[1] which is caused because the bridge doesn\u0026apos;t\nmake sure that all previous garbage has been collected when removing a\nport. What happens is:\n      CPU 1                   CPU 2\n start gc cycle           remove port\n                         acquire gc lock first\n wait for lock\n                         call br_multicasg_gc() directly\n acquire lock now but    free port\n the port can be freed\n while grp timers still\n running\r\n\r\nMake sure all previous gc cycles have finished by using flush_work before\nfreeing the port.\r\n\r\n[1]\n  BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n  Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699\r\n\r\n  CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n  Call Trace:\n   \u0026lt;IRQ\u0026gt;\n   __dump_stack lib/dump_stack.c:88 [inline]\n   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n   print_address_description mm/kasan/report.c:377 [inline]\n   print_report+0xc3/0x620 mm/kasan/report.c:488\n   kasan_report+0xd9/0x110 mm/kasan/report.c:601\n   br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n   call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792\n   expire_timers kernel/time/timer.c:1843 [inline]\n   __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417\n   __run_timer_base kernel/time/timer.c:2428 [inline]\n   __run_timer_base kernel/time/timer.c:2421 [inline]\n   run_timer_base+0x111/0x190 kernel/time/timer.c:2437(CVE-2024-44934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix shift-out-of-bounds in dbDiscardAG\r\n\r\nWhen searching for the next smaller log2 block, BLKSTOL2() returned 0,\ncausing shift exponent -1 to be negative.\r\n\r\nThis patch fixes the issue by exiting the loop directly when negative\nshift is found.(CVE-2024-44938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: ctnetlink: use helper function to calculate expect ID\r\n\r\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.(CVE-2024-44944)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkcm: Serialise kcm_sendmsg() for the same socket.\r\n\r\nsyzkaller reported UAF in kcm_release(). [0]\r\n\r\nThe scenario is\r\n\r\n  1. Thread A builds a skb with MSG_MORE and sets kcm-\u0026gt;seq_skb.\r\n\r\n  2. Thread A resumes building skb from kcm-\u0026gt;seq_skb but is blocked\n     by sk_stream_wait_memory()\r\n\r\n  3. Thread B calls sendmsg() concurrently, finishes building kcm-\u0026gt;seq_skb\n     and puts the skb to the write queue\r\n\r\n  4. Thread A faces an error and finally frees skb that is already in the\n     write queue\r\n\r\n  5. kcm_release() does double-free the skb in the write queue\r\n\r\nWhen a thread is building a MSG_MORE skb, another thread must not touch it.\r\n\r\nLet\u0026apos;s add a per-sk mutex and serialise kcm_sendmsg().\r\n\r\n[0]:\nBUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]\nBUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]\nBUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]\nBUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]\nBUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691\nRead of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167\r\n\r\nCPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall trace:\n dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x178/0x518 mm/kasan/report.c:488\n kasan_report+0xd8/0x138 mm/kasan/report.c:601\n __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381\n __skb_unlink include/linux/skbuff.h:2366 [inline]\n __skb_dequeue include/linux/skbuff.h:2385 [inline]\n __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]\n __skb_queue_purge include/linux/skbuff.h:3181 [inline]\n kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691\n __sock_release net/socket.c:659 [inline]\n sock_close+0xa4/0x1e8 net/socket.c:1421\n __fput+0x30c/0x738 fs/file_table.c:376\n ____fput+0x20/0x30 fs/file_table.c:404\n task_work_run+0x230/0x2e0 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x618/0x1f64 kernel/exit.c:871\n do_group_exit+0x194/0x22c kernel/exit.c:1020\n get_signal+0x1500/0x15ec kernel/signal.c:2893\n do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249\n do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148\n exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]\n exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]\n el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\r\n\r\nAllocated by task 6166:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626\n unpoison_slab_object mm/kasan/common.c:314 [inline]\n __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340\n kasan_slab_alloc include/linux/kasan.h:201 [inline]\n slab_post_alloc_hook mm/slub.c:3813 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903\n __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641\n alloc_skb include/linux/skbuff.h:1296 [inline]\n kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x220/0x2c0 net/socket.c:768\n splice_to_socket+0x7cc/0xd58 fs/splice.c:889\n do_splice_from fs/splice.c:941 [inline]\n direct_splice_actor+0xec/0x1d8 fs/splice.c:1164\n splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108\n do_splice_direct_actor \n---truncated---(CVE-2024-44946)",
  "id": "OESA-2024-2106",
  "modified": "2026-08-06T11:07:34Z",
  "published": "2024-09-06T11:07:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2106"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48811"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48871"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48875"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48877"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48891"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52896"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52906"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40901"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41060"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42230"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42286"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42288"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42295"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42299"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42312"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43824"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43834"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43854"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43890"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43898"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43905"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43908"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44938"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44946"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48811",
    "CVE-2022-48871",
    "CVE-2022-48875",
    "CVE-2022-48877",
    "CVE-2022-48891",
    "CVE-2023-52889",
    "CVE-2023-52896",
    "CVE-2023-52899",
    "CVE-2023-52906",
    "CVE-2024-40901",
    "CVE-2024-41008",
    "CVE-2024-41016",
    "CVE-2024-41060",
    "CVE-2024-41082",
    "CVE-2024-42153",
    "CVE-2024-42230",
    "CVE-2024-42286",
    "CVE-2024-42288",
    "CVE-2024-42295",
    "CVE-2024-42299",
    "CVE-2024-42312",
    "CVE-2024-43824",
    "CVE-2024-43834",
    "CVE-2024-43854",
    "CVE-2024-43883",
    "CVE-2024-43884",
    "CVE-2024-43889",
    "CVE-2024-43890",
    "CVE-2024-43898",
    "CVE-2024-43905",
    "CVE-2024-43908",
    "CVE-2024-44934",
    "CVE-2024-44938",
    "CVE-2024-44944",
    "CVE-2024-44946"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-226.0.0.125.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-226.0.0.125.oe2203sp4"
            }
          ],
          "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\nibmvnic: don\u0026apos;t release napi in __ibmvnic_open()\r\n\r\nIf __ibmvnic_open() encounters an error such as when setting link state,\nit calls release_resources() which frees the napi structures needlessly.\nInstead, have __ibmvnic_open() only clean up the work it did so far (i.e.\ndisable napi and irqs) and leave the rest to the callers.\r\n\r\nIf caller of __ibmvnic_open() is ibmvnic_open(), it should release the\nresources immediately. If the caller is do_reset() or do_hard_reset(),\nthey will release the resources on the next reset.\r\n\r\nThis fixes following crash that occurred when running the drmgr command\nseveral times to add/remove a vnic interface:\r\n\r\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq\n\t[102056] ibmvnic 30000003 env3: Replenished 8 pools\n\tKernel attempted to read user page (10) - exploit attempt? (uid: 0)\n\tBUG: Kernel NULL pointer dereference on read at 0x00000010\n\tFaulting instruction address: 0xc000000000a3c840\n\tOops: Kernel access of bad area, sig: 11 [#1]\n\tLE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n\t...\n\tCPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1\n\tWorkqueue: events_long __ibmvnic_reset [ibmvnic]\n\tNIP:  c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820\n\tREGS: c0000000548e37e0 TRAP: 0300   Not tainted  (5.16.0-rc5-autotest-g6441998e2e37)\n\tMSR:  8000000000009033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt;  CR: 28248484  XER: 00000004\n\tCFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0\n\tGPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000\n\t...\n\tNIP [c000000000a3c840] napi_enable+0x20/0xc0\n\tLR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]\n\tCall Trace:\n\t[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)\n\t[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]\n\t[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]\n\t[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570\n\t[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660\n\t[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0\n\t[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64\n\tInstruction dump:\n\t7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010\n\t38a0fff6 e92d1100 f9210028 39200000 \u0026lt;e9030010\u0026gt; f9010020 60420000 e9210020\n\t---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: Fix null pointer deref when receiving skb during sock creation\r\n\r\nThe panic below is observed when receiving ICMP packets with secmark set\nwhile an ICMP raw socket is being created. SK_CTX(sk)-\u0026gt;label is updated\nin apparmor_socket_post_create(), but the packet is delivered to the\nsocket before that, causing the null pointer dereference.\nDrop the packet if label context is not set.\r\n\r\n    BUG: kernel NULL pointer dereference, address: 000000000000004c\n    #PF: supervisor read access in kernel mode\n    #PF: error_code(0x0000) - not-present page\n    PGD 0 P4D 0\n    Oops: 0000 [#1] PREEMPT SMP NOPTI\n    CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df\n    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020\n    RIP: 0010:aa_label_next_confined+0xb/0x40\n    Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 \u0026lt;8b\u0026gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2\n    RSP: 0018:ffffa92940003b08 EFLAGS: 00010246\n    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e\n    RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000\n    RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002\n    R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400\n    R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000\n    FS:  00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0\n    PKRU: 55555554\n    Call Trace:\n     \u0026lt;IRQ\u0026gt;\n     ? __die+0x23/0x70\n     ? page_fault_oops+0x171/0x4e0\n     ? exc_page_fault+0x7f/0x180\n     ? asm_exc_page_fault+0x26/0x30\n     ? aa_label_next_confined+0xb/0x40\n     apparmor_secmark_check+0xec/0x330\n     security_sock_rcv_skb+0x35/0x50\n     sk_filter_trim_cap+0x47/0x250\n     sock_queue_rcv_skb_reason+0x20/0x60\n     raw_rcv+0x13c/0x210\n     raw_local_deliver+0x1f3/0x250\n     ip_protocol_deliver_rcu+0x4f/0x2f0\n     ip_local_deliver_finish+0x76/0xa0\n     __netif_receive_skb_one_core+0x89/0xa0\n     netif_receive_skb+0x119/0x170\n     ? __netdev_alloc_skb+0x3d/0x140\n     vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n     vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n     __napi_poll+0x28/0x1b0\n     net_rx_action+0x2a4/0x380\n     __do_softirq+0xd1/0x2c8\n     __irq_exit_rcu+0xbb/0xf0\n     common_interrupt+0x86/0xa0\n     \u0026lt;/IRQ\u0026gt;\n     \u0026lt;TASK\u0026gt;\n     asm_common_interrupt+0x26/0x40\n    RIP: 0010:apparmor_socket_post_create+0xb/0x200\n    Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 \u0026lt;55\u0026gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48\n    RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286\n    RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001\n    RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740\n    RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\n    R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003\n    R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748\n     ? __pfx_apparmor_socket_post_create+0x10/0x10\n     security_socket_post_create+0x4b/0x80\n     __sock_create+0x176/0x1f0\n     __sys_socket+0x89/0x100\n     __x64_sys_socket+0x17/0x20\n     do_syscall_64+0x5d/0x90\n     ? do_syscall_64+0x6c/0x90\n     ? do_syscall_64+0x6c/0x90\n     ? do_syscall_64+0x6c/0x90\n     entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: restore set elements when delete set fails\r\n\r\nFrom abort path, nft_mapelem_activate() needs to restore refcounters to\nthe original state. Currently, it uses the set-\u0026gt;ops-\u0026gt;walk() to iterate\nover these set elements. The existing set iterator skips inactive\nelements in the next generation, this does not work from the abort path\nto restore the original state since it has to skip active elements\ninstead (not inactive ones).\r\n\r\nThis patch moves the check for inactive elements to the set iterator\ncallback, then it reverses the logic for the .activate case which\nneeds to skip active elements.\r\n\r\nToggle next generation bit for elements when delete set command is\ninvoked and call nft_clear() from .activate (abort) path to restore the\nnext generation bit.\r\n\r\nThe splat below shows an object in mappings memleak:\r\n\r\n[43929.457523] ------------[ cut here ]------------\n[43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[...]\n[43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 \u0026lt;0f\u0026gt; 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90\n[43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246\n[43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000\n[43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550\n[43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f\n[43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0\n[43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002\n[43929.458103] FS:  00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[43929.458107] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0\n[43929.458114] Call Trace:\n[43929.458118]  \u0026lt;TASK\u0026gt;\n[43929.458121]  ? __warn+0x9f/0x1a0\n[43929.458127]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458188]  ? report_bug+0x1b1/0x1e0\n[43929.458196]  ? handle_bug+0x3c/0x70\n[43929.458200]  ? exc_invalid_op+0x17/0x40\n[43929.458211]  ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables]\n[43929.458271]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]\n[43929.458332]  nft_mapelem_deactivate+0x24/0x30 [nf_tables]\n[43929.458392]  nft_rhash_walk+0xdd/0x180 [nf_tables]\n[43929.458453]  ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables]\n[43929.458512]  ? rb_insert_color+0x2e/0x280\n[43929.458520]  nft_map_deactivate+0xdc/0x1e0 [nf_tables]\n[43929.458582]  ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables]\n[43929.458642]  ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables]\n[43929.458701]  ? __rcu_read_unlock+0x46/0x70\n[43929.458709]  nft_delset+0xff/0x110 [nf_tables]\n[43929.458769]  nft_flush_table+0x16f/0x460 [nf_tables]\n[43929.458830]  nf_tables_deltable+0x501/0x580 [nf_tables](CVE-2024-27012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: do not compare internal table flags on updates\r\n\r\nRestore skipping transaction if table update does not modify flags.(CVE-2024-27065)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential kernel bug due to lack of writeback flag waiting\r\n\r\nDestructive writes to a block device on which nilfs2 is mounted can cause\na kernel bug in the folio/page writeback start routine or writeback end\nroutine (__folio_start_writeback in the log below):\r\n\r\n kernel BUG at mm/page-writeback.c:3070!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n ...\n RIP: 0010:__folio_start_writeback+0xbaa/0x10e0\n Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff\n  e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 \u0026lt;0f\u0026gt;\n  0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]\n  nilfs_segctor_construct+0x181/0x6b0 [nilfs2]\n  nilfs_segctor_thread+0x548/0x11c0 [nilfs2]\n  kthread+0x2f0/0x390\n  ret_from_fork+0x4b/0x80\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because when the log writer starts a writeback for segment summary\nblocks or a super root block that use the backing device\u0026apos;s page cache, it\ndoes not wait for the ongoing folio/page writeback, resulting in an\ninconsistent writeback state.\r\n\r\nFix this issue by waiting for ongoing writebacks when putting\nfolios/pages on the backing device into writeback state.(CVE-2024-37078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory\r\n\r\nThere is a potential out-of-bounds access when using test_bit() on a single\nword. The test_bit() and set_bit() functions operate on long values, and\nwhen testing or setting a single word, they can exceed the word\nboundary. KASAN detects this issue and produces a dump:\r\n\r\n\t BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas\r\n\r\n\t Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965\r\n\r\nFor full log, please look at [1].\r\n\r\nMake the allocation at least the size of sizeof(unsigned long) so that\nset_bit() and test_bit() have sufficient room for read/write operations\nwithout overwriting unallocated memory.\r\n\r\n[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: change vm-\u0026gt;task_info handling\r\n\r\nThis patch changes the handling and lifecycle of vm-\u0026gt;task_info object.\nThe major changes are:\n- vm-\u0026gt;task_info is a dynamically allocated ptr now, and its uasge is\n  reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n    - amdgpu_vm_get_task_info: reference counts up task_info before\n      returning this info\n    - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\r\n\r\nThis patch also does logistical changes required for existing usage\nof vm-\u0026gt;task_info.\r\n\r\nV2: Do not block all the prints when task_info not found (Felix)\r\n\r\nV3: Fixed review comments from Felix\n   - Fix wrong indentation\n   - No debug message for -ENOMEM\n   - Add NULL check for task_info\n   - Do not duplicate the debug messages (ti vs no ti)\n   - Get first reference of task_info in vm_init(), put last\n     in vm_fini()\r\n\r\nV4: Fixed review comments from Felix\n   - fix double reference increment in create_task_info\n   - change amdgpu_vm_get_task_info_pasid\n   - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()\r\n\r\nxattr in ocfs2 maybe \u0026apos;non-indexed\u0026apos;, which saved with additional space\nrequested.  It\u0026apos;s better to check if the memory is out of bound before\nmemcmp, although this possibility mainly comes from crafted poisonous\nimages.(CVE-2024-41016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: check bo_va-\u0026gt;bo is non-NULL before using it\r\n\r\nThe call to radeon_vm_clear_freed might clear bo_va-\u0026gt;bo, so\nwe have to check it before dereferencing it.(CVE-2024-41060)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-fabrics: use reserved tag for reg read/write command\r\n\r\nIn some scenarios, if too many commands are issued by nvme command in\nthe same time by user tasks, this may exhaust all tags of admin_q. If\na reset (nvme reset or IO timeout) occurs before these commands finish,\nreconnect routine may fail to update nvme regs due to insufficient tags,\nwhich will cause kernel hang forever. In order to workaround this issue,\nmaybe we can let reg_read32()/reg_read64()/reg_write32() use reserved\ntags. This maybe safe for nvmf:\r\n\r\n1. For the disable ctrl path,  we will not issue connect command\n2. For the enable ctrl / fw activate path, since connect and reg_xx()\n   are called serially.\r\n\r\nSo the reserved tags may still be enough while reg_xx() use reserved tags.(CVE-2024-41082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\r\n\r\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.(CVE-2024-42153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Fix scv instruction crash with kexec\r\n\r\nkexec on pseries disables AIL (reloc_on_exc), required for scv\ninstruction support, before other CPUs have been shut down. This means\nthey can execute scv instructions after AIL is disabled, which causes an\ninterrupt at an unexpected entry location that crashes the kernel.\r\n\r\nChange the kexec sequence to disable AIL after other CPUs have been\nbrought down.\r\n\r\nAs a refresher, the real-mode scv interrupt vector is 0x17000, and the\nfixed-location head code probably couldn\u0026apos;t easily deal with implementing\nsuch high addresses so it was just decided not to support that interrupt\nat all.(CVE-2024-42230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gem: Fix Virtual Memory mapping boundaries calculation\r\n\r\nCalculating the size of the mapped area as the lesser value\nbetween the requested size and the actual size does not consider\nthe partial mapping offset. This can cause page fault access.\r\n\r\nFix the calculation of the starting and ending addresses, the\ntotal size is now deduced from the difference between the end and\nstart addresses.\r\n\r\nAdditionally, the calculations have been rewritten in a clearer\nand more understandable form.\r\n\r\n[Joonas: Add Requires: tag]\nRequires: 60a2066c5005 (\u0026quot;drm/i915/gem: Adjust vma offset for framebuffer mmap offset\u0026quot;)\n(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()\r\n\r\nHandle VM_FAULT_SIGSEGV in the page fault path so that we correctly\nkill the process and we don\u0026apos;t BUG() the kernel.(CVE-2024-42267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: validate nvme_local_port correctly\r\n\r\nThe driver load failed with error message,\r\n\r\nqla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef\r\n\r\nand with a kernel crash,\r\n\r\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000070\n\tWorkqueue: events_unbound qla_register_fcport_fn [qla2xxx]\n\tRIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]\n\tRSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282\n\tRAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000\n\tRDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000\n\tRBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030\n\tR10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4\n\tR13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8\n\tFS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000\n\tCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\tCR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0\n\tCall Trace:\n\tqla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]\n\t? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]\n\tqla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]\n\tqla_register_fcport_fn+0x54/0xc0 [qla2xxx]\r\n\r\nExit the qla_nvme_register_remote() function when qla_nvme_register_hba()\nfails and correctly validate nvme_local_port.(CVE-2024-42286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Complete command early within lock\r\n\r\nA crash was observed while performing NPIV and FW reset,\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 1 PREEMPT_RT SMP NOPTI\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0\n RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034\n R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000\n FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x16f/0x4a0\n ? do_user_addr_fault+0x174/0x7f0\n ? exc_page_fault+0x69/0x1a0\n ? asm_exc_page_fault+0x22/0x30\n ? dma_direct_unmap_sg+0x51/0x1e0\n ? preempt_count_sub+0x96/0xe0\n qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]\n qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]\n __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]\r\n\r\nThe command completion was done early while aborting the commands in driver\nunload path but outside lock to avoid the WARN_ON condition of performing\ndma_free_attr within the lock. However this caused race condition while\ncommand completion via multiple paths causing system crash.\r\n\r\nHence complete the command early in unload path but within the lock to\navoid race condition.(CVE-2024-42287)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: handle inconsistent state in nilfs_btnode_create_block()\r\n\r\nSyzbot reported that a buffer state inconsistency was detected in\nnilfs_btnode_create_block(), triggering a kernel bug.\r\n\r\nIt is not appropriate to treat this inconsistency as a bug; it can occur\nif the argument block address (the buffer index of the newly created\nblock) is a virtual block number and has been reallocated due to\ncorruption of the bitmap used to manage its allocation state.\r\n\r\nSo, modify nilfs_btnode_create_block() and its callers to treat it as a\npossible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Update log-\u0026gt;page_{mask,bits} if log-\u0026gt;page_size changed\r\n\r\nIf an NTFS file system is mounted to another system with different\nPAGE_SIZE from the original system, log-\u0026gt;page_size will change in\nlog_replay(), but log-\u0026gt;page_{mask,bits} don\u0026apos;t change correspondingly.\nThis will cause a panic because \u0026quot;u32 bytes = log-\u0026gt;page_size - page_off\u0026quot;\nwill get a negative value in the later read_log_page().(CVE-2024-42299)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysctl: always initialize i_uid/i_gid\r\n\r\nAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()\ncan safely skip setting them.\r\n\r\nCommit 5ec27ec735ba (\u0026quot;fs/proc/proc_sysctl.c: fix the default values of\ni_uid/i_gid on /proc/sys inodes.\u0026quot;) added defaults for i_uid/i_gid when\nset_ownership() was not implemented. It also missed adjusting\nnet_ctl_set_ownership() to use the same default values in case the\ncomputation of a better value failed.(CVE-2024-42312)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: endpoint: pci-epf-test: Make use of cached \u0026apos;epc_features\u0026apos; in pci_epf_test_core_init()\r\n\r\nInstead of getting the epc_features from pci_epc_get_features() API, use\nthe cached pci_epf_test::epc_features value to avoid the NULL check. Since\nthe NULL check is already performed in pci_epf_test_bind(), having one more\ncheck in pci_epf_test_core_init() is redundant and it is not possible to\nhit the NULL pointer dereference.\r\n\r\nAlso with commit a01e7214bef9 (\u0026quot;PCI: endpoint: Remove \u0026quot;core_init_notifier\u0026quot;\nflag\u0026quot;), \u0026apos;epc_features\u0026apos; got dereferenced without the NULL check, leading to\nthe following false positive Smatch warning:\r\n\r\n  drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed \u0026apos;epc_features\u0026apos; could be null (see line 747)\r\n\r\nThus, remove the redundant NULL check and also use the epc_features::\n{msix_capable/msi_capable} flags directly to avoid local variables.\r\n\r\n[kwilczynski: commit log](CVE-2024-43824)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxdp: fix invalid wait context of page_pool_destroy()\r\n\r\nIf the driver uses a page pool, it creates a page pool with\npage_pool_create().\nThe reference count of page pool is 1 as default.\nA page pool will be destroyed only when a reference count reaches 0.\npage_pool_destroy() is used to destroy page pool, it decreases a\nreference count.\nWhen a page pool is destroyed, -\u0026gt;disconnect() is called, which is\nmem_allocator_disconnect().\nThis function internally acquires mutex_lock().\r\n\r\nIf the driver uses XDP, it registers a memory model with\nxdp_rxq_info_reg_mem_model().\nThe xdp_rxq_info_reg_mem_model() internally increases a page pool\nreference count if a memory model is a page pool.\nNow the reference count is 2.\r\n\r\nTo destroy a page pool, the driver should call both page_pool_destroy()\nand xdp_unreg_mem_model().\nThe xdp_unreg_mem_model() internally calls page_pool_destroy().\nOnly page_pool_destroy() decreases a reference count.\r\n\r\nIf a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we\nwill face an invalid wait context warning.\nBecause xdp_unreg_mem_model() calls page_pool_destroy() with\nrcu_read_lock().\nThe page_pool_destroy() internally acquires mutex_lock().\r\n\r\nSplat looks like:\n=============================\n[ BUG: Invalid wait context ]\n6.10.0-rc6+ #4 Tainted: G W\n-----------------------------\nethtool/1806 is trying to lock:\nffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150\nother info that might help us debug this:\ncontext-{5:5}\n3 locks held by ethtool/1806:\nstack backtrace:\nCPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x7e/0xc0\n__lock_acquire+0x1681/0x4de0\n? _printk+0x64/0xe0\n? __pfx_mark_lock.part.0+0x10/0x10\n? __pfx___lock_acquire+0x10/0x10\nlock_acquire+0x1b3/0x580\n? mem_allocator_disconnect+0x73/0x150\n? __wake_up_klogd.part.0+0x16/0xc0\n? __pfx_lock_acquire+0x10/0x10\n? dump_stack_lvl+0x91/0xc0\n__mutex_lock+0x15c/0x1690\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_prb_read_valid+0x10/0x10\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_llist_add_batch+0x10/0x10\n? console_unlock+0x193/0x1b0\n? lockdep_hardirqs_on+0xbe/0x140\n? __pfx___mutex_lock+0x10/0x10\n? tick_nohz_tick_stopped+0x16/0x90\n? __irq_work_queue_local+0x1e5/0x330\n? irq_work_queue+0x39/0x50\n? __wake_up_klogd.part.0+0x79/0xc0\n? mem_allocator_disconnect+0x73/0x150\nmem_allocator_disconnect+0x73/0x150\n? __pfx_mem_allocator_disconnect+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? rcu_is_watching+0x11/0xb0\npage_pool_release+0x36e/0x6d0\npage_pool_destroy+0xd7/0x440\nxdp_unreg_mem_model+0x1a7/0x2a0\n? __pfx_xdp_unreg_mem_model+0x10/0x10\n? kfree+0x125/0x370\n? bnxt_free_ring.isra.0+0x2eb/0x500\n? bnxt_free_mem+0x5ac/0x2500\nxdp_rxq_info_unreg+0x4a/0xd0\nbnxt_free_mem+0x1356/0x2500\nbnxt_close_nic+0xf0/0x3b0\n? __pfx_bnxt_close_nic+0x10/0x10\n? ethnl_parse_bit+0x2c6/0x6d0\n? __pfx___nla_validate_parse+0x10/0x10\n? __pfx_ethnl_parse_bit+0x10/0x10\nbnxt_set_features+0x2a8/0x3e0\n__netdev_update_features+0x4dc/0x1370\n? ethnl_parse_bitset+0x4ff/0x750\n? __pfx_ethnl_parse_bitset+0x10/0x10\n? __pfx___netdev_update_features+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? _raw_spin_unlock_irqrestore+0x42/0x70\n? __pm_runtime_resume+0x7d/0x110\nethnl_set_features+0x32d/0xa20\r\n\r\nTo fix this problem, it uses rhashtable_lookup_fast() instead of\nrhashtable_lookup() with rcu_read_lock().\nUsing xa without rcu_read_lock() here is safe.\nxa is freed by __xdp_mem_allocator_rcu_free() and this is called by\ncall_rcu() of mem_xa_remove().\nThe mem_xa_remove() is called by page_pool_destroy() if a reference\ncount reaches 0.\nThe xa is already protected by the reference count mechanism well in the\ncontrol plane.\nSo removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: initialize integrity buffer to zero before writing it to media\r\n\r\nMetadata added by bio_integrity_prep is using plain kmalloc, which leads\nto random kernel memory being written media.  For PI metadata this is\nlimited to the app tag that isn\u0026apos;t used by kernel generated metadata,\nbut for non-PI metadata the entire buffer leaks kernel memory.\r\n\r\nFix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: vhci-hcd: Do not drop references before new references are gained\r\n\r\nAt a few places the driver carries stale pointers\nto references that can still be used. Make sure that does not happen.\nThis strictly speaking closes ZDI-CAN-22273, though there may be\nsimilar races in the driver.(CVE-2024-43883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: MGMT: Add error handling to pair_device()\r\n\r\nhci_conn_params_add() never checks for a NULL value and could lead to a NULL\npointer dereference causing a crash.\r\n\r\nFixed by adding error handling in the function.(CVE-2024-43884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npadata: Fix possible divide-by-0 panic in padata_mt_helper()\r\n\r\nWe are hit with a not easily reproducible divide-by-0 panic in padata.c at\nbootup time.\r\n\r\n  [   10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI\n  [   10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1\n  [   10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021\n  [   10.017908] Workqueue: events_unbound padata_mt_helper\n  [   10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0\n    :\n  [   10.017963] Call Trace:\n  [   10.017968]  \u0026lt;TASK\u0026gt;\n  [   10.018004]  ? padata_mt_helper+0x39/0xb0\n  [   10.018084]  process_one_work+0x174/0x330\n  [   10.018093]  worker_thread+0x266/0x3a0\n  [   10.018111]  kthread+0xcf/0x100\n  [   10.018124]  ret_from_fork+0x31/0x50\n  [   10.018138]  ret_from_fork_asm+0x1a/0x30\n  [   10.018147]  \u0026lt;/TASK\u0026gt;\r\n\r\nLooking at the padata_mt_helper() function, the only way a divide-by-0\npanic can happen is when ps-\u0026gt;chunk_size is 0.  The way that chunk_size is\ninitialized in padata_do_multithreaded(), chunk_size can be 0 when the\nmin_chunk in the passed-in padata_mt_job structure is 0.\r\n\r\nFix this divide-by-0 panic by making sure that chunk_size will be at least\n1 no matter what the input parameters are.(CVE-2024-43889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Fix overflow in get_free_elt()\r\n\r\n\u0026quot;tracing_map-\u0026gt;next_elt\u0026quot; in get_free_elt() is at risk of overflowing.\r\n\r\nOnce it overflows, new elements can still be inserted into the tracing_map\neven though the maximum number of elements (`max_elts`) has been reached.\nContinuing to insert elements after the overflow could result in the\ntracing_map containing \u0026quot;tracing_map-\u0026gt;max_size\u0026quot; elements, leaving no empty\nentries.\nIf any attempt is made to insert an element into a full tracing_map using\n`__tracing_map_insert()`, it will cause an infinite loop with preemption\ndisabled, leading to a CPU hang problem.\r\n\r\nFix this by preventing any further increments to \u0026quot;tracing_map-\u0026gt;next_elt\u0026quot;\nonce it reaches \u0026quot;tracing_map-\u0026gt;max_elt\u0026quot;.(CVE-2024-43890)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: sanity check for NULL pointer after ext4_force_shutdown\r\n\r\nTest case: 2 threads write short inline data to a file.\nIn ext4_page_mkwrite the resulting inline data is converted.\nHandling ext4_grp_locked_error with description \u0026quot;block bitmap\nand bg descriptor inconsistent: X vs Y free clusters\u0026quot; calls\next4_force_shutdown. The conversion clears\nEXT4_STATE_MAY_INLINE_DATA but fails for\next4_destroy_inline_data_nolock and ext4_mark_iloc_dirty due\nto ext4_forced_shutdown. The restoration of inline data fails\nfor the same reason not setting EXT4_STATE_MAY_INLINE_DATA.\nWithout the flag set a regular process path in ext4_da_write_end\nfollows trying to dereference page folio private pointer that has\nnot been set. The fix calls early return with -EIO error shall the\npointer to private be NULL.\r\n\r\nSample crash report:\r\n\r\nUnable to handle kernel paging request at virtual address dfff800000000004\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nMem abort info:\n  ESR = 0x0000000096000005\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x05: level 1 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[dfff800000000004] address between user and kernel address ranges\nInternal error: Oops: 0000000096000005 [#1] PREEMPT SMP\nModules linked in:\nCPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\nlr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160\nsp : ffff8000a1957600\nx29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0\nx26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000\nx23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020\nx20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196\nx17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0\nx14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020\nx2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0\nCall trace:\n __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\n block_write_end+0xb4/0x104 fs/buffer.c:2253\n ext4_da_do_write_end fs/ext4/inode.c:2955 [inline]\n ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028\n generic_perform_write+0x394/0x588 mm/filemap.c:3985\n ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299\n ext4_file_write_iter+0x188/0x1780\n call_write_iter include/linux/fs.h:2110 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x968/0xc3c fs/read_write.c:590\n ksys_write+0x15c/0x26c fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __arm64_sys_write+0x7c/0x90 fs/read_write.c:652\n __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\nCode: 97f85911 f94002da 91008356 d343fec8 (38796908)\n---[ end trace 0000000000000000 ]---\n----------------\nCode disassembly (best guess):\n   0:\t97f85911 \tbl\t0xffffffffffe16444\n   4:\tf94002da \tldr\tx26, [x22]\n   8:\t91008356 \tadd\tx22, x26, #0x20\n   c:\td343fec8 \tlsr\tx8, x22, #3\n* 10:\t38796908 \tldrb\tw8, [x8, x25] \u0026lt;-- trapping instruction(CVE-2024-43898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add null checker before passing variables\r\n\r\nChecks null pointer before passing variables to functions.\r\n\r\nThis fixes 3 NULL_RETURNS issues reported by Coverity.(CVE-2024-43902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: Fix the null pointer dereference for vega10_hwmgr\r\n\r\nCheck return value and conduct null pointer handling to avoid null pointer dereference.(CVE-2024-43905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix the null pointer dereference to ras_manager\r\n\r\nCheck ras_manager before using it(CVE-2024-43908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: mcast: wait for previous gc cycles when removing port\r\n\r\nsyzbot hit a use-after-free[1] which is caused because the bridge doesn\u0026apos;t\nmake sure that all previous garbage has been collected when removing a\nport. What happens is:\n      CPU 1                   CPU 2\n start gc cycle           remove port\n                         acquire gc lock first\n wait for lock\n                         call br_multicasg_gc() directly\n acquire lock now but    free port\n the port can be freed\n while grp timers still\n running\r\n\r\nMake sure all previous gc cycles have finished by using flush_work before\nfreeing the port.\r\n\r\n[1]\n  BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n  Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699\r\n\r\n  CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n  Call Trace:\n   \u0026lt;IRQ\u0026gt;\n   __dump_stack lib/dump_stack.c:88 [inline]\n   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n   print_address_description mm/kasan/report.c:377 [inline]\n   print_report+0xc3/0x620 mm/kasan/report.c:488\n   kasan_report+0xd9/0x110 mm/kasan/report.c:601\n   br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n   call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792\n   expire_timers kernel/time/timer.c:1843 [inline]\n   __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417\n   __run_timer_base kernel/time/timer.c:2428 [inline]\n   __run_timer_base kernel/time/timer.c:2421 [inline]\n   run_timer_base+0x111/0x190 kernel/time/timer.c:2437(CVE-2024-44934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix shift-out-of-bounds in dbDiscardAG\r\n\r\nWhen searching for the next smaller log2 block, BLKSTOL2() returned 0,\ncausing shift exponent -1 to be negative.\r\n\r\nThis patch fixes the issue by exiting the loop directly when negative\nshift is found.(CVE-2024-44938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC\r\n\r\nsyzbot reports a f2fs bug as below:\r\n\r\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/inline.c:258!\nCPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0\nRIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258\nCall Trace:\n f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834\n f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]\n __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]\n f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315\n do_writepages+0x35b/0x870 mm/page-writeback.c:2612\n __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650\n writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941\n wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117\n wb_do_writeback fs/fs-writeback.c:2264 [inline]\n wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335\n worker_thread+0x86d/0xd70 kernel/workqueue.c:3416\n kthread+0x2f2/0x390 kernel/kthread.c:388\n ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\r\n\r\nThe root cause is: inline_data inode can be fuzzed, so that there may\nbe valid blkaddr in its direct node, once f2fs triggers background GC\nto migrate the block, it will hit f2fs_bug_on() during dirty page\nwriteback.\r\n\r\nLet\u0026apos;s add sanity check on F2FS_INLINE_DATA flag in inode during GC,\nso that, it can forbid migrating inline_data inode\u0026apos;s data block for\nfixing.(CVE-2024-44942)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: ctnetlink: use helper function to calculate expect ID\r\n\r\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.(CVE-2024-44944)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkcm: Serialise kcm_sendmsg() for the same socket.\r\n\r\nsyzkaller reported UAF in kcm_release(). [0]\r\n\r\nThe scenario is\r\n\r\n  1. Thread A builds a skb with MSG_MORE and sets kcm-\u0026gt;seq_skb.\r\n\r\n  2. Thread A resumes building skb from kcm-\u0026gt;seq_skb but is blocked\n     by sk_stream_wait_memory()\r\n\r\n  3. Thread B calls sendmsg() concurrently, finishes building kcm-\u0026gt;seq_skb\n     and puts the skb to the write queue\r\n\r\n  4. Thread A faces an error and finally frees skb that is already in the\n     write queue\r\n\r\n  5. kcm_release() does double-free the skb in the write queue\r\n\r\nWhen a thread is building a MSG_MORE skb, another thread must not touch it.\r\n\r\nLet\u0026apos;s add a per-sk mutex and serialise kcm_sendmsg().\r\n\r\n[0]:\nBUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]\nBUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]\nBUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]\nBUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]\nBUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691\nRead of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167\r\n\r\nCPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall trace:\n dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x178/0x518 mm/kasan/report.c:488\n kasan_report+0xd8/0x138 mm/kasan/report.c:601\n __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381\n __skb_unlink include/linux/skbuff.h:2366 [inline]\n __skb_dequeue include/linux/skbuff.h:2385 [inline]\n __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]\n __skb_queue_purge include/linux/skbuff.h:3181 [inline]\n kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691\n __sock_release net/socket.c:659 [inline]\n sock_close+0xa4/0x1e8 net/socket.c:1421\n __fput+0x30c/0x738 fs/file_table.c:376\n ____fput+0x20/0x30 fs/file_table.c:404\n task_work_run+0x230/0x2e0 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x618/0x1f64 kernel/exit.c:871\n do_group_exit+0x194/0x22c kernel/exit.c:1020\n get_signal+0x1500/0x15ec kernel/signal.c:2893\n do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249\n do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148\n exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]\n exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]\n el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\r\n\r\nAllocated by task 6166:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626\n unpoison_slab_object mm/kasan/common.c:314 [inline]\n __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340\n kasan_slab_alloc include/linux/kasan.h:201 [inline]\n slab_post_alloc_hook mm/slub.c:3813 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903\n __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641\n alloc_skb include/linux/skbuff.h:1296 [inline]\n kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x220/0x2c0 net/socket.c:768\n splice_to_socket+0x7cc/0xd58 fs/splice.c:889\n do_splice_from fs/splice.c:941 [inline]\n direct_splice_actor+0xec/0x1d8 fs/splice.c:1164\n splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108\n do_splice_direct_actor \n---truncated---(CVE-2024-44946)",
  "id": "OESA-2024-2107",
  "modified": "2026-08-06T11:07:34Z",
  "published": "2024-09-06T11:07:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2107"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48811"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27012"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27065"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37078"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40901"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41060"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42230"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42259"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42267"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42286"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42287"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42295"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42299"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42312"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43824"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43834"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43854"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43890"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43898"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43902"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43905"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43908"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44938"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44946"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48811",
    "CVE-2023-52889",
    "CVE-2024-27012",
    "CVE-2024-27065",
    "CVE-2024-37078",
    "CVE-2024-40901",
    "CVE-2024-41008",
    "CVE-2024-41016",
    "CVE-2024-41060",
    "CVE-2024-41082",
    "CVE-2024-42153",
    "CVE-2024-42230",
    "CVE-2024-42259",
    "CVE-2024-42267",
    "CVE-2024-42286",
    "CVE-2024-42287",
    "CVE-2024-42295",
    "CVE-2024-42299",
    "CVE-2024-42312",
    "CVE-2024-43824",
    "CVE-2024-43834",
    "CVE-2024-43854",
    "CVE-2024-43883",
    "CVE-2024-43884",
    "CVE-2024-43889",
    "CVE-2024-43890",
    "CVE-2024-43898",
    "CVE-2024-43902",
    "CVE-2024-43905",
    "CVE-2024-43908",
    "CVE-2024-44934",
    "CVE-2024-44938",
    "CVE-2024-44942",
    "CVE-2024-44944",
    "CVE-2024-44946"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-226.0.0.129.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-226.0.0.129.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-226.0.0.129.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-226.0.0.129.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-226.0.0.129.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\nibmvnic: don\u0026apos;t release napi in __ibmvnic_open()\r\n\r\nIf __ibmvnic_open() encounters an error such as when setting link state,\nit calls release_resources() which frees the napi structures needlessly.\nInstead, have __ibmvnic_open() only clean up the work it did so far (i.e.\ndisable napi and irqs) and leave the rest to the callers.\r\n\r\nIf caller of __ibmvnic_open() is ibmvnic_open(), it should release the\nresources immediately. If the caller is do_reset() or do_hard_reset(),\nthey will release the resources on the next reset.\r\n\r\nThis fixes following crash that occurred when running the drmgr command\nseveral times to add/remove a vnic interface:\r\n\r\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq\n\t[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq\n\t[102056] ibmvnic 30000003 env3: Replenished 8 pools\n\tKernel attempted to read user page (10) - exploit attempt? (uid: 0)\n\tBUG: Kernel NULL pointer dereference on read at 0x00000010\n\tFaulting instruction address: 0xc000000000a3c840\n\tOops: Kernel access of bad area, sig: 11 [#1]\n\tLE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n\t...\n\tCPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1\n\tWorkqueue: events_long __ibmvnic_reset [ibmvnic]\n\tNIP:  c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820\n\tREGS: c0000000548e37e0 TRAP: 0300   Not tainted  (5.16.0-rc5-autotest-g6441998e2e37)\n\tMSR:  8000000000009033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt;  CR: 28248484  XER: 00000004\n\tCFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0\n\tGPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000\n\t...\n\tNIP [c000000000a3c840] napi_enable+0x20/0xc0\n\tLR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]\n\tCall Trace:\n\t[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)\n\t[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]\n\t[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]\n\t[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570\n\t[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660\n\t[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0\n\t[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64\n\tInstruction dump:\n\t7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010\n\t38a0fff6 e92d1100 f9210028 39200000 \u0026lt;e9030010\u0026gt; f9010020 60420000 e9210020\n\t---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: Fix null pointer deref when receiving skb during sock creation\r\n\r\nThe panic below is observed when receiving ICMP packets with secmark set\nwhile an ICMP raw socket is being created. SK_CTX(sk)-\u0026gt;label is updated\nin apparmor_socket_post_create(), but the packet is delivered to the\nsocket before that, causing the null pointer dereference.\nDrop the packet if label context is not set.\r\n\r\n    BUG: kernel NULL pointer dereference, address: 000000000000004c\n    #PF: supervisor read access in kernel mode\n    #PF: error_code(0x0000) - not-present page\n    PGD 0 P4D 0\n    Oops: 0000 [#1] PREEMPT SMP NOPTI\n    CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df\n    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020\n    RIP: 0010:aa_label_next_confined+0xb/0x40\n    Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 \u0026lt;8b\u0026gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2\n    RSP: 0018:ffffa92940003b08 EFLAGS: 00010246\n    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e\n    RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000\n    RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002\n    R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400\n    R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000\n    FS:  00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0\n    PKRU: 55555554\n    Call Trace:\n     \u0026lt;IRQ\u0026gt;\n     ? __die+0x23/0x70\n     ? page_fault_oops+0x171/0x4e0\n     ? exc_page_fault+0x7f/0x180\n     ? asm_exc_page_fault+0x26/0x30\n     ? aa_label_next_confined+0xb/0x40\n     apparmor_secmark_check+0xec/0x330\n     security_sock_rcv_skb+0x35/0x50\n     sk_filter_trim_cap+0x47/0x250\n     sock_queue_rcv_skb_reason+0x20/0x60\n     raw_rcv+0x13c/0x210\n     raw_local_deliver+0x1f3/0x250\n     ip_protocol_deliver_rcu+0x4f/0x2f0\n     ip_local_deliver_finish+0x76/0xa0\n     __netif_receive_skb_one_core+0x89/0xa0\n     netif_receive_skb+0x119/0x170\n     ? __netdev_alloc_skb+0x3d/0x140\n     vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n     vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n     __napi_poll+0x28/0x1b0\n     net_rx_action+0x2a4/0x380\n     __do_softirq+0xd1/0x2c8\n     __irq_exit_rcu+0xbb/0xf0\n     common_interrupt+0x86/0xa0\n     \u0026lt;/IRQ\u0026gt;\n     \u0026lt;TASK\u0026gt;\n     asm_common_interrupt+0x26/0x40\n    RIP: 0010:apparmor_socket_post_create+0xb/0x200\n    Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 \u0026lt;55\u0026gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48\n    RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286\n    RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001\n    RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740\n    RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\n    R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003\n    R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748\n     ? __pfx_apparmor_socket_post_create+0x10/0x10\n     security_socket_post_create+0x4b/0x80\n     __sock_create+0x176/0x1f0\n     __sys_socket+0x89/0x100\n     __x64_sys_socket+0x17/0x20\n     do_syscall_64+0x5d/0x90\n     ? do_syscall_64+0x6c/0x90\n     ? do_syscall_64+0x6c/0x90\n     ? do_syscall_64+0x6c/0x90\n     entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory\r\n\r\nThere is a potential out-of-bounds access when using test_bit() on a single\nword. The test_bit() and set_bit() functions operate on long values, and\nwhen testing or setting a single word, they can exceed the word\nboundary. KASAN detects this issue and produces a dump:\r\n\r\n\t BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas\r\n\r\n\t Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965\r\n\r\nFor full log, please look at [1].\r\n\r\nMake the allocation at least the size of sizeof(unsigned long) so that\nset_bit() and test_bit() have sufficient room for read/write operations\nwithout overwriting unallocated memory.\r\n\r\n[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: change vm-\u0026gt;task_info handling\r\n\r\nThis patch changes the handling and lifecycle of vm-\u0026gt;task_info object.\nThe major changes are:\n- vm-\u0026gt;task_info is a dynamically allocated ptr now, and its uasge is\n  reference counted.\n- introducing two new helper funcs for task_info lifecycle management\n    - amdgpu_vm_get_task_info: reference counts up task_info before\n      returning this info\n    - amdgpu_vm_put_task_info: reference counts down task_info\n- last put to task_info() frees task_info from the vm.\r\n\r\nThis patch also does logistical changes required for existing usage\nof vm-\u0026gt;task_info.\r\n\r\nV2: Do not block all the prints when task_info not found (Felix)\r\n\r\nV3: Fixed review comments from Felix\n   - Fix wrong indentation\n   - No debug message for -ENOMEM\n   - Add NULL check for task_info\n   - Do not duplicate the debug messages (ti vs no ti)\n   - Get first reference of task_info in vm_init(), put last\n     in vm_fini()\r\n\r\nV4: Fixed review comments from Felix\n   - fix double reference increment in create_task_info\n   - change amdgpu_vm_get_task_info_pasid\n   - additional changes in amdgpu_gem.c while porting(CVE-2024-41008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()\r\n\r\nxattr in ocfs2 maybe \u0026apos;non-indexed\u0026apos;, which saved with additional space\nrequested.  It\u0026apos;s better to check if the memory is out of bound before\nmemcmp, although this possibility mainly comes from crafted poisonous\nimages.(CVE-2024-41016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: check bo_va-\u0026gt;bo is non-NULL before using it\r\n\r\nThe call to radeon_vm_clear_freed might clear bo_va-\u0026gt;bo, so\nwe have to check it before dereferencing it.(CVE-2024-41060)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-fabrics: use reserved tag for reg read/write command\r\n\r\nIn some scenarios, if too many commands are issued by nvme command in\nthe same time by user tasks, this may exhaust all tags of admin_q. If\na reset (nvme reset or IO timeout) occurs before these commands finish,\nreconnect routine may fail to update nvme regs due to insufficient tags,\nwhich will cause kernel hang forever. In order to workaround this issue,\nmaybe we can let reg_read32()/reg_read64()/reg_write32() use reserved\ntags. This maybe safe for nvmf:\r\n\r\n1. For the disable ctrl path,  we will not issue connect command\n2. For the enable ctrl / fw activate path, since connect and reg_xx()\n   are called serially.\r\n\r\nSo the reserved tags may still be enough while reg_xx() use reserved tags.(CVE-2024-41082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\r\n\r\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.(CVE-2024-42153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Fix scv instruction crash with kexec\r\n\r\nkexec on pseries disables AIL (reloc_on_exc), required for scv\ninstruction support, before other CPUs have been shut down. This means\nthey can execute scv instructions after AIL is disabled, which causes an\ninterrupt at an unexpected entry location that crashes the kernel.\r\n\r\nChange the kexec sequence to disable AIL after other CPUs have been\nbrought down.\r\n\r\nAs a refresher, the real-mode scv interrupt vector is 0x17000, and the\nfixed-location head code probably couldn\u0026apos;t easily deal with implementing\nsuch high addresses so it was just decided not to support that interrupt\nat all.(CVE-2024-42230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gem: Fix Virtual Memory mapping boundaries calculation\r\n\r\nCalculating the size of the mapped area as the lesser value\nbetween the requested size and the actual size does not consider\nthe partial mapping offset. This can cause page fault access.\r\n\r\nFix the calculation of the starting and ending addresses, the\ntotal size is now deduced from the difference between the end and\nstart addresses.\r\n\r\nAdditionally, the calculations have been rewritten in a clearer\nand more understandable form.\r\n\r\n[Joonas: Add Requires: tag]\nRequires: 60a2066c5005 (\u0026quot;drm/i915/gem: Adjust vma offset for framebuffer mmap offset\u0026quot;)\n(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()\r\n\r\nHandle VM_FAULT_SIGSEGV in the page fault path so that we correctly\nkill the process and we don\u0026apos;t BUG() the kernel.(CVE-2024-42267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: validate nvme_local_port correctly\r\n\r\nThe driver load failed with error message,\r\n\r\nqla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef\r\n\r\nand with a kernel crash,\r\n\r\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000070\n\tWorkqueue: events_unbound qla_register_fcport_fn [qla2xxx]\n\tRIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]\n\tRSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282\n\tRAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000\n\tRDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000\n\tRBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030\n\tR10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4\n\tR13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8\n\tFS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000\n\tCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\tCR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0\n\tCall Trace:\n\tqla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]\n\t? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]\n\tqla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]\n\tqla_register_fcport_fn+0x54/0xc0 [qla2xxx]\r\n\r\nExit the qla_nvme_register_remote() function when qla_nvme_register_hba()\nfails and correctly validate nvme_local_port.(CVE-2024-42286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Complete command early within lock\r\n\r\nA crash was observed while performing NPIV and FW reset,\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 1 PREEMPT_RT SMP NOPTI\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0\n RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034\n R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000\n FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x16f/0x4a0\n ? do_user_addr_fault+0x174/0x7f0\n ? exc_page_fault+0x69/0x1a0\n ? asm_exc_page_fault+0x22/0x30\n ? dma_direct_unmap_sg+0x51/0x1e0\n ? preempt_count_sub+0x96/0xe0\n qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]\n qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]\n __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]\r\n\r\nThe command completion was done early while aborting the commands in driver\nunload path but outside lock to avoid the WARN_ON condition of performing\ndma_free_attr within the lock. However this caused race condition while\ncommand completion via multiple paths causing system crash.\r\n\r\nHence complete the command early in unload path but within the lock to\navoid race condition.(CVE-2024-42287)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: handle inconsistent state in nilfs_btnode_create_block()\r\n\r\nSyzbot reported that a buffer state inconsistency was detected in\nnilfs_btnode_create_block(), triggering a kernel bug.\r\n\r\nIt is not appropriate to treat this inconsistency as a bug; it can occur\nif the argument block address (the buffer index of the newly created\nblock) is a virtual block number and has been reallocated due to\ncorruption of the bitmap used to manage its allocation state.\r\n\r\nSo, modify nilfs_btnode_create_block() and its callers to treat it as a\npossible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Update log-\u0026gt;page_{mask,bits} if log-\u0026gt;page_size changed\r\n\r\nIf an NTFS file system is mounted to another system with different\nPAGE_SIZE from the original system, log-\u0026gt;page_size will change in\nlog_replay(), but log-\u0026gt;page_{mask,bits} don\u0026apos;t change correspondingly.\nThis will cause a panic because \u0026quot;u32 bytes = log-\u0026gt;page_size - page_off\u0026quot;\nwill get a negative value in the later read_log_page().(CVE-2024-42299)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysctl: always initialize i_uid/i_gid\r\n\r\nAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()\ncan safely skip setting them.\r\n\r\nCommit 5ec27ec735ba (\u0026quot;fs/proc/proc_sysctl.c: fix the default values of\ni_uid/i_gid on /proc/sys inodes.\u0026quot;) added defaults for i_uid/i_gid when\nset_ownership() was not implemented. It also missed adjusting\nnet_ctl_set_ownership() to use the same default values in case the\ncomputation of a better value failed.(CVE-2024-42312)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: endpoint: pci-epf-test: Make use of cached \u0026apos;epc_features\u0026apos; in pci_epf_test_core_init()\r\n\r\nInstead of getting the epc_features from pci_epc_get_features() API, use\nthe cached pci_epf_test::epc_features value to avoid the NULL check. Since\nthe NULL check is already performed in pci_epf_test_bind(), having one more\ncheck in pci_epf_test_core_init() is redundant and it is not possible to\nhit the NULL pointer dereference.\r\n\r\nAlso with commit a01e7214bef9 (\u0026quot;PCI: endpoint: Remove \u0026quot;core_init_notifier\u0026quot;\nflag\u0026quot;), \u0026apos;epc_features\u0026apos; got dereferenced without the NULL check, leading to\nthe following false positive Smatch warning:\r\n\r\n  drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed \u0026apos;epc_features\u0026apos; could be null (see line 747)\r\n\r\nThus, remove the redundant NULL check and also use the epc_features::\n{msix_capable/msi_capable} flags directly to avoid local variables.\r\n\r\n[kwilczynski: commit log](CVE-2024-43824)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxdp: fix invalid wait context of page_pool_destroy()\r\n\r\nIf the driver uses a page pool, it creates a page pool with\npage_pool_create().\nThe reference count of page pool is 1 as default.\nA page pool will be destroyed only when a reference count reaches 0.\npage_pool_destroy() is used to destroy page pool, it decreases a\nreference count.\nWhen a page pool is destroyed, -\u0026gt;disconnect() is called, which is\nmem_allocator_disconnect().\nThis function internally acquires mutex_lock().\r\n\r\nIf the driver uses XDP, it registers a memory model with\nxdp_rxq_info_reg_mem_model().\nThe xdp_rxq_info_reg_mem_model() internally increases a page pool\nreference count if a memory model is a page pool.\nNow the reference count is 2.\r\n\r\nTo destroy a page pool, the driver should call both page_pool_destroy()\nand xdp_unreg_mem_model().\nThe xdp_unreg_mem_model() internally calls page_pool_destroy().\nOnly page_pool_destroy() decreases a reference count.\r\n\r\nIf a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we\nwill face an invalid wait context warning.\nBecause xdp_unreg_mem_model() calls page_pool_destroy() with\nrcu_read_lock().\nThe page_pool_destroy() internally acquires mutex_lock().\r\n\r\nSplat looks like:\n=============================\n[ BUG: Invalid wait context ]\n6.10.0-rc6+ #4 Tainted: G W\n-----------------------------\nethtool/1806 is trying to lock:\nffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150\nother info that might help us debug this:\ncontext-{5:5}\n3 locks held by ethtool/1806:\nstack backtrace:\nCPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x7e/0xc0\n__lock_acquire+0x1681/0x4de0\n? _printk+0x64/0xe0\n? __pfx_mark_lock.part.0+0x10/0x10\n? __pfx___lock_acquire+0x10/0x10\nlock_acquire+0x1b3/0x580\n? mem_allocator_disconnect+0x73/0x150\n? __wake_up_klogd.part.0+0x16/0xc0\n? __pfx_lock_acquire+0x10/0x10\n? dump_stack_lvl+0x91/0xc0\n__mutex_lock+0x15c/0x1690\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_prb_read_valid+0x10/0x10\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_llist_add_batch+0x10/0x10\n? console_unlock+0x193/0x1b0\n? lockdep_hardirqs_on+0xbe/0x140\n? __pfx___mutex_lock+0x10/0x10\n? tick_nohz_tick_stopped+0x16/0x90\n? __irq_work_queue_local+0x1e5/0x330\n? irq_work_queue+0x39/0x50\n? __wake_up_klogd.part.0+0x79/0xc0\n? mem_allocator_disconnect+0x73/0x150\nmem_allocator_disconnect+0x73/0x150\n? __pfx_mem_allocator_disconnect+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? rcu_is_watching+0x11/0xb0\npage_pool_release+0x36e/0x6d0\npage_pool_destroy+0xd7/0x440\nxdp_unreg_mem_model+0x1a7/0x2a0\n? __pfx_xdp_unreg_mem_model+0x10/0x10\n? kfree+0x125/0x370\n? bnxt_free_ring.isra.0+0x2eb/0x500\n? bnxt_free_mem+0x5ac/0x2500\nxdp_rxq_info_unreg+0x4a/0xd0\nbnxt_free_mem+0x1356/0x2500\nbnxt_close_nic+0xf0/0x3b0\n? __pfx_bnxt_close_nic+0x10/0x10\n? ethnl_parse_bit+0x2c6/0x6d0\n? __pfx___nla_validate_parse+0x10/0x10\n? __pfx_ethnl_parse_bit+0x10/0x10\nbnxt_set_features+0x2a8/0x3e0\n__netdev_update_features+0x4dc/0x1370\n? ethnl_parse_bitset+0x4ff/0x750\n? __pfx_ethnl_parse_bitset+0x10/0x10\n? __pfx___netdev_update_features+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? _raw_spin_unlock_irqrestore+0x42/0x70\n? __pm_runtime_resume+0x7d/0x110\nethnl_set_features+0x32d/0xa20\r\n\r\nTo fix this problem, it uses rhashtable_lookup_fast() instead of\nrhashtable_lookup() with rcu_read_lock().\nUsing xa without rcu_read_lock() here is safe.\nxa is freed by __xdp_mem_allocator_rcu_free() and this is called by\ncall_rcu() of mem_xa_remove().\nThe mem_xa_remove() is called by page_pool_destroy() if a reference\ncount reaches 0.\nThe xa is already protected by the reference count mechanism well in the\ncontrol plane.\nSo removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: initialize integrity buffer to zero before writing it to media\r\n\r\nMetadata added by bio_integrity_prep is using plain kmalloc, which leads\nto random kernel memory being written media.  For PI metadata this is\nlimited to the app tag that isn\u0026apos;t used by kernel generated metadata,\nbut for non-PI metadata the entire buffer leaks kernel memory.\r\n\r\nFix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: vhci-hcd: Do not drop references before new references are gained\r\n\r\nAt a few places the driver carries stale pointers\nto references that can still be used. Make sure that does not happen.\nThis strictly speaking closes ZDI-CAN-22273, though there may be\nsimilar races in the driver.(CVE-2024-43883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: MGMT: Add error handling to pair_device()\r\n\r\nhci_conn_params_add() never checks for a NULL value and could lead to a NULL\npointer dereference causing a crash.\r\n\r\nFixed by adding error handling in the function.(CVE-2024-43884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npadata: Fix possible divide-by-0 panic in padata_mt_helper()\r\n\r\nWe are hit with a not easily reproducible divide-by-0 panic in padata.c at\nbootup time.\r\n\r\n  [   10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI\n  [   10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1\n  [   10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021\n  [   10.017908] Workqueue: events_unbound padata_mt_helper\n  [   10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0\n    :\n  [   10.017963] Call Trace:\n  [   10.017968]  \u0026lt;TASK\u0026gt;\n  [   10.018004]  ? padata_mt_helper+0x39/0xb0\n  [   10.018084]  process_one_work+0x174/0x330\n  [   10.018093]  worker_thread+0x266/0x3a0\n  [   10.018111]  kthread+0xcf/0x100\n  [   10.018124]  ret_from_fork+0x31/0x50\n  [   10.018138]  ret_from_fork_asm+0x1a/0x30\n  [   10.018147]  \u0026lt;/TASK\u0026gt;\r\n\r\nLooking at the padata_mt_helper() function, the only way a divide-by-0\npanic can happen is when ps-\u0026gt;chunk_size is 0.  The way that chunk_size is\ninitialized in padata_do_multithreaded(), chunk_size can be 0 when the\nmin_chunk in the passed-in padata_mt_job structure is 0.\r\n\r\nFix this divide-by-0 panic by making sure that chunk_size will be at least\n1 no matter what the input parameters are.(CVE-2024-43889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Fix overflow in get_free_elt()\r\n\r\n\u0026quot;tracing_map-\u0026gt;next_elt\u0026quot; in get_free_elt() is at risk of overflowing.\r\n\r\nOnce it overflows, new elements can still be inserted into the tracing_map\neven though the maximum number of elements (`max_elts`) has been reached.\nContinuing to insert elements after the overflow could result in the\ntracing_map containing \u0026quot;tracing_map-\u0026gt;max_size\u0026quot; elements, leaving no empty\nentries.\nIf any attempt is made to insert an element into a full tracing_map using\n`__tracing_map_insert()`, it will cause an infinite loop with preemption\ndisabled, leading to a CPU hang problem.\r\n\r\nFix this by preventing any further increments to \u0026quot;tracing_map-\u0026gt;next_elt\u0026quot;\nonce it reaches \u0026quot;tracing_map-\u0026gt;max_elt\u0026quot;.(CVE-2024-43890)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: sanity check for NULL pointer after ext4_force_shutdown\r\n\r\nTest case: 2 threads write short inline data to a file.\nIn ext4_page_mkwrite the resulting inline data is converted.\nHandling ext4_grp_locked_error with description \u0026quot;block bitmap\nand bg descriptor inconsistent: X vs Y free clusters\u0026quot; calls\next4_force_shutdown. The conversion clears\nEXT4_STATE_MAY_INLINE_DATA but fails for\next4_destroy_inline_data_nolock and ext4_mark_iloc_dirty due\nto ext4_forced_shutdown. The restoration of inline data fails\nfor the same reason not setting EXT4_STATE_MAY_INLINE_DATA.\nWithout the flag set a regular process path in ext4_da_write_end\nfollows trying to dereference page folio private pointer that has\nnot been set. The fix calls early return with -EIO error shall the\npointer to private be NULL.\r\n\r\nSample crash report:\r\n\r\nUnable to handle kernel paging request at virtual address dfff800000000004\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nMem abort info:\n  ESR = 0x0000000096000005\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x05: level 1 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[dfff800000000004] address between user and kernel address ranges\nInternal error: Oops: 0000000096000005 [#1] PREEMPT SMP\nModules linked in:\nCPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\nlr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160\nsp : ffff8000a1957600\nx29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0\nx26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000\nx23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020\nx20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196\nx17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0\nx14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020\nx2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0\nCall trace:\n __block_commit_write+0x64/0x2b0 fs/buffer.c:2167\n block_write_end+0xb4/0x104 fs/buffer.c:2253\n ext4_da_do_write_end fs/ext4/inode.c:2955 [inline]\n ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028\n generic_perform_write+0x394/0x588 mm/filemap.c:3985\n ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299\n ext4_file_write_iter+0x188/0x1780\n call_write_iter include/linux/fs.h:2110 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x968/0xc3c fs/read_write.c:590\n ksys_write+0x15c/0x26c fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __arm64_sys_write+0x7c/0x90 fs/read_write.c:652\n __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\nCode: 97f85911 f94002da 91008356 d343fec8 (38796908)\n---[ end trace 0000000000000000 ]---\n----------------\nCode disassembly (best guess):\n   0:\t97f85911 \tbl\t0xffffffffffe16444\n   4:\tf94002da \tldr\tx26, [x22]\n   8:\t91008356 \tadd\tx22, x26, #0x20\n   c:\td343fec8 \tlsr\tx8, x22, #3\n* 10:\t38796908 \tldrb\tw8, [x8, x25] \u0026lt;-- trapping instruction(CVE-2024-43898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add null checker before passing variables\r\n\r\nChecks null pointer before passing variables to functions.\r\n\r\nThis fixes 3 NULL_RETURNS issues reported by Coverity.(CVE-2024-43902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: Fix the null pointer dereference for vega10_hwmgr\r\n\r\nCheck return value and conduct null pointer handling to avoid null pointer dereference.(CVE-2024-43905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix the null pointer dereference to ras_manager\r\n\r\nCheck ras_manager before using it(CVE-2024-43908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: mcast: wait for previous gc cycles when removing port\r\n\r\nsyzbot hit a use-after-free[1] which is caused because the bridge doesn\u0026apos;t\nmake sure that all previous garbage has been collected when removing a\nport. What happens is:\n      CPU 1                   CPU 2\n start gc cycle           remove port\n                         acquire gc lock first\n wait for lock\n                         call br_multicasg_gc() directly\n acquire lock now but    free port\n the port can be freed\n while grp timers still\n running\r\n\r\nMake sure all previous gc cycles have finished by using flush_work before\nfreeing the port.\r\n\r\n[1]\n  BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n  Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699\r\n\r\n  CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n  Call Trace:\n   \u0026lt;IRQ\u0026gt;\n   __dump_stack lib/dump_stack.c:88 [inline]\n   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n   print_address_description mm/kasan/report.c:377 [inline]\n   print_report+0xc3/0x620 mm/kasan/report.c:488\n   kasan_report+0xd9/0x110 mm/kasan/report.c:601\n   br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n   call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792\n   expire_timers kernel/time/timer.c:1843 [inline]\n   __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417\n   __run_timer_base kernel/time/timer.c:2428 [inline]\n   __run_timer_base kernel/time/timer.c:2421 [inline]\n   run_timer_base+0x111/0x190 kernel/time/timer.c:2437(CVE-2024-44934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix shift-out-of-bounds in dbDiscardAG\r\n\r\nWhen searching for the next smaller log2 block, BLKSTOL2() returned 0,\ncausing shift exponent -1 to be negative.\r\n\r\nThis patch fixes the issue by exiting the loop directly when negative\nshift is found.(CVE-2024-44938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC\r\n\r\nsyzbot reports a f2fs bug as below:\r\n\r\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/inline.c:258!\nCPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0\nRIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258\nCall Trace:\n f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834\n f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]\n __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]\n f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315\n do_writepages+0x35b/0x870 mm/page-writeback.c:2612\n __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650\n writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941\n wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117\n wb_do_writeback fs/fs-writeback.c:2264 [inline]\n wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335\n worker_thread+0x86d/0xd70 kernel/workqueue.c:3416\n kthread+0x2f2/0x390 kernel/kthread.c:388\n ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\r\n\r\nThe root cause is: inline_data inode can be fuzzed, so that there may\nbe valid blkaddr in its direct node, once f2fs triggers background GC\nto migrate the block, it will hit f2fs_bug_on() during dirty page\nwriteback.\r\n\r\nLet\u0026apos;s add sanity check on F2FS_INLINE_DATA flag in inode during GC,\nso that, it can forbid migrating inline_data inode\u0026apos;s data block for\nfixing.(CVE-2024-44942)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: ctnetlink: use helper function to calculate expect ID\r\n\r\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.(CVE-2024-44944)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkcm: Serialise kcm_sendmsg() for the same socket.\r\n\r\nsyzkaller reported UAF in kcm_release(). [0]\r\n\r\nThe scenario is\r\n\r\n  1. Thread A builds a skb with MSG_MORE and sets kcm-\u0026gt;seq_skb.\r\n\r\n  2. Thread A resumes building skb from kcm-\u0026gt;seq_skb but is blocked\n     by sk_stream_wait_memory()\r\n\r\n  3. Thread B calls sendmsg() concurrently, finishes building kcm-\u0026gt;seq_skb\n     and puts the skb to the write queue\r\n\r\n  4. Thread A faces an error and finally frees skb that is already in the\n     write queue\r\n\r\n  5. kcm_release() does double-free the skb in the write queue\r\n\r\nWhen a thread is building a MSG_MORE skb, another thread must not touch it.\r\n\r\nLet\u0026apos;s add a per-sk mutex and serialise kcm_sendmsg().\r\n\r\n[0]:\nBUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]\nBUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]\nBUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]\nBUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]\nBUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691\nRead of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167\r\n\r\nCPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall trace:\n dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x178/0x518 mm/kasan/report.c:488\n kasan_report+0xd8/0x138 mm/kasan/report.c:601\n __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381\n __skb_unlink include/linux/skbuff.h:2366 [inline]\n __skb_dequeue include/linux/skbuff.h:2385 [inline]\n __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]\n __skb_queue_purge include/linux/skbuff.h:3181 [inline]\n kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691\n __sock_release net/socket.c:659 [inline]\n sock_close+0xa4/0x1e8 net/socket.c:1421\n __fput+0x30c/0x738 fs/file_table.c:376\n ____fput+0x20/0x30 fs/file_table.c:404\n task_work_run+0x230/0x2e0 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x618/0x1f64 kernel/exit.c:871\n do_group_exit+0x194/0x22c kernel/exit.c:1020\n get_signal+0x1500/0x15ec kernel/signal.c:2893\n do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249\n do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148\n exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]\n exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]\n el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\r\n\r\nAllocated by task 6166:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626\n unpoison_slab_object mm/kasan/common.c:314 [inline]\n __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340\n kasan_slab_alloc include/linux/kasan.h:201 [inline]\n slab_post_alloc_hook mm/slub.c:3813 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903\n __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641\n alloc_skb include/linux/skbuff.h:1296 [inline]\n kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x220/0x2c0 net/socket.c:768\n splice_to_socket+0x7cc/0xd58 fs/splice.c:889\n do_splice_from fs/splice.c:941 [inline]\n direct_splice_actor+0xec/0x1d8 fs/splice.c:1164\n splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108\n do_splice_direct_actor \n---truncated---(CVE-2024-44946)",
  "id": "OESA-2024-2108",
  "modified": "2026-08-06T11:07:35Z",
  "published": "2024-09-06T11:07:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2108"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48811"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40901"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41060"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42230"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42259"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42267"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42286"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42287"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42295"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42299"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42312"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43824"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43834"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43854"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43890"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43898"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43902"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43905"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43908"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44938"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44946"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48811",
    "CVE-2023-52889",
    "CVE-2024-40901",
    "CVE-2024-41008",
    "CVE-2024-41016",
    "CVE-2024-41060",
    "CVE-2024-41082",
    "CVE-2024-42153",
    "CVE-2024-42230",
    "CVE-2024-42259",
    "CVE-2024-42267",
    "CVE-2024-42286",
    "CVE-2024-42287",
    "CVE-2024-42295",
    "CVE-2024-42299",
    "CVE-2024-42312",
    "CVE-2024-43824",
    "CVE-2024-43834",
    "CVE-2024-43854",
    "CVE-2024-43883",
    "CVE-2024-43884",
    "CVE-2024-43889",
    "CVE-2024-43890",
    "CVE-2024-43898",
    "CVE-2024-43902",
    "CVE-2024-43905",
    "CVE-2024-43908",
    "CVE-2024-44934",
    "CVE-2024-44938",
    "CVE-2024-44942",
    "CVE-2024-44944",
    "CVE-2024-44946"
  ]
}