{
  "$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
  "affected_systems": [
    {
      "description": "SUSE Linux Enterprise Micro for Rancher 5.3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "Legacy Module 15-SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "openSUSE Leap Micro 5.5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Performance Computing 15 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Manager Proxy 4.2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Desktop 15 SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server for SAP Applications 15 SP2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Micro 5.3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Manager Proxy 4.3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "Basesystem Module 15-SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Micro for Rancher 5.2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Real Time Module 15-SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Performance Computing 12 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "Public Cloud Module 15-SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Desktop 15 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 12 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Availability Extension 15 SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "Public Cloud Module 15-SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Micro for Rancher 5.4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Live Patching 15-SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Manager Retail Branch Server 4.3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Availability Extension 15 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Live Patching 15-SP3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "openSUSE Leap 15.4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Real Time 12 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Live Patching 15-SP2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server for SAP Applications 15 SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "openSUSE Leap 15.5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Manager Server 4.3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Manager Retail Branch Server 4.1",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Availability Extension 12 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Performance Computing 15 SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Performance Computing 15 SP2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Availability Extension 15 SP3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Live Patching 15-SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server for SAP Applications 15 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Real Time 15 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "Legacy Module 15-SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Live Patching 12-SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Workstation Extension 12 12-SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Manager Retail Branch Server 4.2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "Confidential Computing Module 15-SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Live Patching 15-SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Manager Server 4.1",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Micro 5.2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Real Time 15 SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "openSUSE Leap 15.6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Enterprise Storage 7.1",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Real Time Module 15-SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Availability Extension 15 SP2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP3 Business Critical Linux 15-SP3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP2 Business Critical Linux 15-SP2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Real Time 15 SP4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Software Development Kit 12 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Manager Proxy 4.1",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Manager Server 4.2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "Basesystem Module 15-SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Workstation Extension 15 SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Performance Computing 15 SP3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server for SAP Applications 15 SP3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Workstation Extension 15 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server for SAP Applications 12 SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "Development Tools Module 15-SP5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Micro 5.1",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Micro 5.4",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "openSUSE Leap 15.3",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise High Availability Extension 15 SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP2",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "Development Tools Module 15-SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Server 15 SP6",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    },
    {
      "description": "SUSE Linux Enterprise Micro 5.5",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "SUSE",
          "scada": false
        }
      }
    }
  ],
  "affected_systems_content": null,
  "content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
  "cves": [
    {
      "name": "CVE-2024-27024",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-27024"
    },
    {
      "name": "CVE-2022-48945",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48945"
    },
    {
      "name": "CVE-2024-44984",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44984"
    },
    {
      "name": "CVE-2024-46755",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46755"
    },
    {
      "name": "CVE-2024-45020",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45020"
    },
    {
      "name": "CVE-2024-46826",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
    },
    {
      "name": "CVE-2024-46770",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46770"
    },
    {
      "name": "CVE-2024-43914",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43914"
    },
    {
      "name": "CVE-2024-37353",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-37353"
    },
    {
      "name": "CVE-2024-46676",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46676"
    },
    {
      "name": "CVE-2024-41082",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-41082"
    },
    {
      "name": "CVE-2024-46798",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46798"
    },
    {
      "name": "CVE-2024-40973",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-40973"
    },
    {
      "name": "CVE-2024-46735",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46735"
    },
    {
      "name": "CVE-2024-43898",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43898"
    },
    {
      "name": "CVE-2024-46707",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46707"
    },
    {
      "name": "CVE-2024-45029",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45029"
    },
    {
      "name": "CVE-2024-41000",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-41000"
    },
    {
      "name": "CVE-2024-46751",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46751"
    },
    {
      "name": "CVE-2024-46710",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46710"
    },
    {
      "name": "CVE-2024-43845",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43845"
    },
    {
      "name": "CVE-2024-46747",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46747"
    },
    {
      "name": "CVE-2024-45002",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45002"
    },
    {
      "name": "CVE-2024-44961",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44961"
    },
    {
      "name": "CVE-2024-46738",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46738"
    },
    {
      "name": "CVE-2024-46775",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46775"
    },
    {
      "name": "CVE-2024-46679",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
    },
    {
      "name": "CVE-2024-46734",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46734"
    },
    {
      "name": "CVE-2024-46855",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46855"
    },
    {
      "name": "CVE-2024-46673",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46673"
    },
    {
      "name": "CVE-2024-43886",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43886"
    },
    {
      "name": "CVE-2024-26767",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-26767"
    },
    {
      "name": "CVE-2024-46724",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46724"
    },
    {
      "name": "CVE-2024-46791",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46791"
    },
    {
      "name": "CVE-2024-44986",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44986"
    },
    {
      "name": "CVE-2024-38632",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-38632"
    },
    {
      "name": "CVE-2024-44969",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44969"
    },
    {
      "name": "CVE-2024-46787",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46787"
    },
    {
      "name": "CVE-2024-45026",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45026"
    },
    {
      "name": "CVE-2024-44946",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44946"
    },
    {
      "name": "CVE-2024-46750",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46750"
    },
    {
      "name": "CVE-2024-44970",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44970"
    },
    {
      "name": "CVE-2022-48788",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48788"
    },
    {
      "name": "CVE-2024-46722",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46722"
    },
    {
      "name": "CVE-2022-48799",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48799"
    },
    {
      "name": "CVE-2024-45015",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45015"
    },
    {
      "name": "CVE-2024-38596",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-38596"
    },
    {
      "name": "CVE-2024-46745",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46745"
    },
    {
      "name": "CVE-2024-46721",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46721"
    },
    {
      "name": "CVE-2024-46822",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46822"
    },
    {
      "name": "CVE-2024-44991",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44991"
    },
    {
      "name": "CVE-2024-46692",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46692"
    },
    {
      "name": "CVE-2024-42154",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42154"
    },
    {
      "name": "CVE-2024-46685",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46685"
    },
    {
      "name": "CVE-2024-45000",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45000"
    },
    {
      "name": "CVE-2024-43828",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43828"
    },
    {
      "name": "CVE-2024-42306",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42306"
    },
    {
      "name": "CVE-2024-44998",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44998"
    },
    {
      "name": "CVE-2022-48923",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48923"
    },
    {
      "name": "CVE-2024-46723",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46723"
    },
    {
      "name": "CVE-2022-48935",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48935"
    },
    {
      "name": "CVE-2022-48790",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48790"
    },
    {
      "name": "CVE-2024-46675",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46675"
    },
    {
      "name": "CVE-2024-46783",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46783"
    },
    {
      "name": "CVE-2024-45018",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45018"
    },
    {
      "name": "CVE-2022-48791",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48791"
    },
    {
      "name": "CVE-2024-42305",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42305"
    },
    {
      "name": "CVE-2024-45030",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45030"
    },
    {
      "name": "CVE-2024-46715",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46715"
    },
    {
      "name": "CVE-2024-46689",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46689"
    },
    {
      "name": "CVE-2024-46781",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46781"
    },
    {
      "name": "CVE-2024-45023",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45023"
    },
    {
      "name": "CVE-2024-46741",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46741"
    },
    {
      "name": "CVE-2022-48789",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48789"
    },
    {
      "name": "CVE-2023-52916",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-52916"
    },
    {
      "name": "CVE-2024-46776",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46776"
    },
    {
      "name": "CVE-2024-46714",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46714"
    },
    {
      "name": "CVE-2024-44960",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44960"
    },
    {
      "name": "CVE-2024-44962",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44962"
    },
    {
      "name": "CVE-2024-46857",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46857"
    },
    {
      "name": "CVE-2024-44971",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44971"
    },
    {
      "name": "CVE-2024-46731",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46731"
    },
    {
      "name": "CVE-2024-46674",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46674"
    },
    {
      "name": "CVE-2024-26804",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-26804"
    },
    {
      "name": "CVE-2024-46859",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46859"
    },
    {
      "name": "CVE-2024-43912",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43912"
    },
    {
      "name": "CVE-2024-46767",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46767"
    },
    {
      "name": "CVE-2024-44944",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44944"
    },
    {
      "name": "CVE-2024-40983",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-40983"
    },
    {
      "name": "CVE-2024-46784",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46784"
    },
    {
      "name": "CVE-2024-42259",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42259"
    },
    {
      "name": "CVE-2024-46757",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46757"
    },
    {
      "name": "CVE-2024-46677",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46677"
    },
    {
      "name": "CVE-2024-44935",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
    },
    {
      "name": "CVE-2024-44999",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44999"
    },
    {
      "name": "CVE-2023-52766",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-52766"
    },
    {
      "name": "CVE-2024-46749",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46749"
    },
    {
      "name": "CVE-2024-44988",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44988"
    },
    {
      "name": "CVE-2024-46830",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46830"
    },
    {
      "name": "CVE-2024-46773",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46773"
    },
    {
      "name": "CVE-2024-46727",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46727"
    },
    {
      "name": "CVE-2024-41073",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-41073"
    },
    {
      "name": "CVE-2021-47622",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-47622"
    },
    {
      "name": "CVE-2024-41079",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
    },
    {
      "name": "CVE-2024-46854",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46854"
    },
    {
      "name": "CVE-2021-47387",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-47387"
    },
    {
      "name": "CVE-2024-46758",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46758"
    },
    {
      "name": "CVE-2024-45005",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45005"
    },
    {
      "name": "CVE-2024-46746",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46746"
    },
    {
      "name": "CVE-2024-46756",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46756"
    },
    {
      "name": "CVE-2024-46739",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46739"
    },
    {
      "name": "CVE-2024-44967",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44967"
    },
    {
      "name": "CVE-2024-46709",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46709"
    },
    {
      "name": "CVE-2024-45006",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45006"
    },
    {
      "name": "CVE-2024-46725",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46725"
    },
    {
      "name": "CVE-2024-44954",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44954"
    },
    {
      "name": "CVE-2024-26837",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-26837"
    },
    {
      "name": "CVE-2024-46695",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46695"
    },
    {
      "name": "CVE-2024-43890",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43890"
    },
    {
      "name": "CVE-2024-46778",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46778"
    },
    {
      "name": "CVE-2022-48911",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48911"
    },
    {
      "name": "CVE-2024-45001",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45001"
    },
    {
      "name": "CVE-2024-44977",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44977"
    },
    {
      "name": "CVE-2024-44972",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44972"
    },
    {
      "name": "CVE-2024-44952",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44952"
    },
    {
      "name": "CVE-2024-36971",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-36971"
    },
    {
      "name": "CVE-2024-46797",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46797"
    },
    {
      "name": "CVE-2024-46743",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46743"
    },
    {
      "name": "CVE-2024-46786",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46786"
    },
    {
      "name": "CVE-2024-46691",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46691"
    },
    {
      "name": "CVE-2024-41087",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
    },
    {
      "name": "CVE-2024-40965",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-40965"
    },
    {
      "name": "CVE-2024-46744",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46744"
    },
    {
      "name": "CVE-2024-42294",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42294"
    },
    {
      "name": "CVE-2024-40910",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-40910"
    },
    {
      "name": "CVE-2024-44950",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44950"
    },
    {
      "name": "CVE-2024-46774",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46774"
    },
    {
      "name": "CVE-2024-45007",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45007"
    },
    {
      "name": "CVE-2024-46780",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46780"
    },
    {
      "name": "CVE-2022-48943",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48943"
    },
    {
      "name": "CVE-2024-26640",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-26640"
    },
    {
      "name": "CVE-2021-4442",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-4442"
    },
    {
      "name": "CVE-2024-46771",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46771"
    },
    {
      "name": "CVE-2024-46717",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46717"
    },
    {
      "name": "CVE-2024-42304",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42304"
    },
    {
      "name": "CVE-2024-43835",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43835"
    },
    {
      "name": "CVE-2023-52752",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-52752"
    },
    {
      "name": "CVE-2024-46794",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46794"
    },
    {
      "name": "CVE-2024-46711",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46711"
    },
    {
      "name": "CVE-2024-45017",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45017"
    },
    {
      "name": "CVE-2021-47408",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-47408"
    },
    {
      "name": "CVE-2024-46732",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46732"
    },
    {
      "name": "CVE-2024-45012",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45012"
    },
    {
      "name": "CVE-2024-46753",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46753"
    },
    {
      "name": "CVE-2024-46759",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46759"
    },
    {
      "name": "CVE-2024-43832",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43832"
    },
    {
      "name": "CVE-2024-45022",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45022"
    },
    {
      "name": "CVE-2024-46720",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46720"
    },
    {
      "name": "CVE-2024-46737",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46737"
    },
    {
      "name": "CVE-2022-48901",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48901"
    },
    {
      "name": "CVE-2024-44997",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44997"
    },
    {
      "name": "CVE-2024-45019",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45019"
    },
    {
      "name": "CVE-2024-42252",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42252"
    },
    {
      "name": "CVE-2024-43884",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43884"
    },
    {
      "name": "CVE-2024-44965",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44965"
    },
    {
      "name": "CVE-2024-45003",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45003"
    },
    {
      "name": "CVE-2024-46686",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46686"
    },
    {
      "name": "CVE-2024-46678",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46678"
    },
    {
      "name": "CVE-2024-26759",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-26759"
    },
    {
      "name": "CVE-2024-46752",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46752"
    },
    {
      "name": "CVE-2024-45021",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45021"
    },
    {
      "name": "CVE-2024-43870",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43870"
    },
    {
      "name": "CVE-2024-44951",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44951"
    },
    {
      "name": "CVE-2023-52610",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-52610"
    },
    {
      "name": "CVE-2023-52915",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-52915"
    },
    {
      "name": "CVE-2024-45013",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45013"
    },
    {
      "name": "CVE-2024-46729",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46729"
    },
    {
      "name": "CVE-2024-46761",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46761"
    },
    {
      "name": "CVE-2024-38381",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-38381"
    },
    {
      "name": "CVE-2021-47069",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-47069"
    },
    {
      "name": "CVE-2024-41062",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
    },
    {
      "name": "CVE-2024-46687",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46687"
    },
    {
      "name": "CVE-2024-46853",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46853"
    },
    {
      "name": "CVE-2024-43904",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-43904"
    },
    {
      "name": "CVE-2024-46706",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46706"
    },
    {
      "name": "CVE-2024-45008",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45008"
    },
    {
      "name": "CVE-2024-46726",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46726"
    },
    {
      "name": "CVE-2024-44990",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
    },
    {
      "name": "CVE-2024-42265",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42265"
    },
    {
      "name": "CVE-2024-44987",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44987"
    },
    {
      "name": "CVE-2024-44982",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44982"
    },
    {
      "name": "CVE-2024-46730",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46730"
    },
    {
      "name": "CVE-2024-46728",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46728"
    },
    {
      "name": "CVE-2022-48844",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48844"
    },
    {
      "name": "CVE-2024-46694",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46694"
    },
    {
      "name": "CVE-2024-45011",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45011"
    },
    {
      "name": "CVE-2024-46772",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46772"
    },
    {
      "name": "CVE-2024-45028",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45028"
    },
    {
      "name": "CVE-2024-42301",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
    },
    {
      "name": "CVE-2022-48944",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-48944"
    },
    {
      "name": "CVE-2024-46702",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46702"
    },
    {
      "name": "CVE-2021-47620",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-47620"
    },
    {
      "name": "CVE-2024-46719",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46719"
    },
    {
      "name": "CVE-2024-44947",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44947"
    },
    {
      "name": "CVE-2024-38538",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-38538"
    },
    {
      "name": "CVE-2024-44985",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44985"
    },
    {
      "name": "CVE-2024-46693",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46693"
    },
    {
      "name": "CVE-2024-46760",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46760"
    },
    {
      "name": "CVE-2024-36953",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-36953"
    },
    {
      "name": "CVE-2024-44948",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44948"
    },
    {
      "name": "CVE-2024-42243",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-42243"
    },
    {
      "name": "CVE-2024-46716",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46716"
    },
    {
      "name": "CVE-2024-46672",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-46672"
    },
    {
      "name": "CVE-2024-44989",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
    }
  ],
  "initial_release_date": "2024-10-11T00:00:00",
  "last_revision_date": "2024-10-11T00:00:00",
  "links": [],
  "reference": "CERTFR-2024-AVI-0870",
  "revisions": [
    {
      "description": "Version initiale",
      "revision_date": "2024-10-11T00:00:00.000000"
    }
  ],
  "risks": [
    {
      "description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
    },
    {
      "description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
    },
    {
      "description": "D\u00e9ni de service"
    },
    {
      "description": "Contournement de la politique de s\u00e9curit\u00e9"
    },
    {
      "description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
    }
  ],
  "summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de SUSE. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es, une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es et un contournement de la politique de s\u00e9curit\u00e9.",
  "title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de SUSE",
  "vendor_advisories": [
    {
      "published_at": "2024-10-08",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3551-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243551-1"
    },
    {
      "published_at": "2024-10-10",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3585-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243585-1"
    },
    {
      "published_at": "2024-10-09",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3561-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243561-1"
    },
    {
      "published_at": "2024-10-09",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3559-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243559-1"
    },
    {
      "published_at": "2024-10-09",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3563-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243563-1"
    },
    {
      "published_at": "2024-10-09",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3567-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243567-1"
    },
    {
      "published_at": "2024-10-10",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3591-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243591-1"
    },
    {
      "published_at": "2024-10-08",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3553-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243553-1"
    },
    {
      "published_at": "2024-10-08",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3547-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243547-1"
    },
    {
      "published_at": "2024-10-09",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3565-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243565-1"
    },
    {
      "published_at": "2024-10-10",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3587-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243587-1"
    },
    {
      "published_at": "2024-10-09",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3566-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243566-1"
    },
    {
      "published_at": "2024-10-10",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3592-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243592-1"
    },
    {
      "published_at": "2024-10-09",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3564-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243564-1"
    },
    {
      "published_at": "2024-10-09",
      "title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:3569-1",
      "url": "https://www.suse.com/support/update/announcement/2024/suse-su-20243569-1"
    }
  ]
}

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
    }
  ],
  "id": "CVE-2024-37353",
  "lastModified": "2024-08-22T00:15:05.760",
  "metrics": {},
  "published": "2024-06-21T11:15:10.590",
  "references": [],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Rejected"
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-37353"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-21T11:15:10Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio: delete vq in vp_find_vqs_msix() when request_irq() fails\n\nWhen request_irq() fails, error path calls vp_del_vqs(). There, as vq is\npresent in the list, free_irq() is called for the same vector. That\ncauses following splat:\n\n[    0.414355] Trying to free already-free IRQ 27\n[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0\n[    0.414510] Modules linked in:\n[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27\n[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014\n[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0\n[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 \u003c0f\u003e 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40\n[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086\n[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000\n[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001\n[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001\n[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760\n[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600\n[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000\n[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0\n[    0.414540] Call Trace:\n[    0.414540]  \u003cTASK\u003e\n[    0.414540]  ? __warn+0x80/0x120\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  ? report_bug+0x164/0x190\n[    0.414540]  ? handle_bug+0x3b/0x70\n[    0.414540]  ? exc_invalid_op+0x17/0x70\n[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  vp_del_vqs+0xc1/0x220\n[    0.414540]  vp_find_vqs_msix+0x305/0x470\n[    0.414540]  vp_find_vqs+0x3e/0x1a0\n[    0.414540]  vp_modern_find_vqs+0x1b/0x70\n[    0.414540]  init_vqs+0x387/0x600\n[    0.414540]  virtnet_probe+0x50a/0xc80\n[    0.414540]  virtio_dev_probe+0x1e0/0x2b0\n[    0.414540]  really_probe+0xc0/0x2c0\n[    0.414540]  ? __pfx___driver_attach+0x10/0x10\n[    0.414540]  __driver_probe_device+0x73/0x120\n[    0.414540]  driver_probe_device+0x1f/0xe0\n[    0.414540]  __driver_attach+0x88/0x180\n[    0.414540]  bus_for_each_dev+0x85/0xd0\n[    0.414540]  bus_add_driver+0xec/0x1f0\n[    0.414540]  driver_register+0x59/0x100\n[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10\n[    0.414540]  virtio_net_driver_init+0x90/0xb0\n[    0.414540]  do_one_initcall+0x58/0x230\n[    0.414540]  kernel_init_freeable+0x1a3/0x2d0\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  kernel_init+0x1a/0x1c0\n[    0.414540]  ret_from_fork+0x31/0x50\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  ret_from_fork_asm+0x1a/0x30\n[    0.414540]  \u003c/TASK\u003e\n\nFix this by calling deleting the current vq when request_irq() fails.",
  "id": "GHSA-qr49-prx4-cw5w",
  "modified": "2024-06-27T15:30:40Z",
  "published": "2024-06-21T12:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37353"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/04207a9c64e0b16dac842e5b2ecfa53af25bdea7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/42d30da50d5c1ec433fd9551bfddd6887407c352"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/43a9aaf63254ab821f0f25fea25698ebe69ea16a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7fbe54f02a5c77ff5dd65e8ed0b58e3bd8c43e9c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/89875151fccdd024d571aa884ea97a0128b968b6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/abf001651acd1858252764fa39d79e3d0b5c86b2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bb61a84793858330ba2ca1d202d3779096f6fb54"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cb7a7c8144b434e06aba99b13b045a7efe859587"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2407.1.0.0284.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2407.1.0.0284.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2407.1.0.0284.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Medium"
  },
  "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\nnet: ethernet: fix potential use-after-free in ec_bhf_remove\r\n\r\nstatic void ec_bhf_remove(struct pci_dev *dev)\n{\n...\n\tstruct ec_bhf_priv *priv = netdev_priv(net_dev);\r\n\r\n\tunregister_netdev(net_dev);\n\tfree_netdev(net_dev);\r\n\r\n\tpci_iounmap(dev, priv-\u0026gt;dma_io);\n\tpci_iounmap(dev, priv-\u0026gt;io);\n...\n}\r\n\r\npriv is netdev private data, but it is used\nafter free_netdev(). It can cause use-after-free when accessing priv\npointer. So, fix it by moving free_netdev() after pci_iounmap()\ncalls.(CVE-2021-47235)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47285)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac80211: track only QoS data frames for admission control\r\n\r\nFor admission control, obviously all of that only works for\nQoS data frames, otherwise we cannot even access the QoS\nfield in the header.\r\n\r\nSyzbot reported (see below) an uninitialized value here due\nto a status of a non-QoS nullfunc packet, which isn\u0026apos;t even\nlong enough to contain the QoS header.\r\n\r\nFix this to only do anything for QoS data packets.(CVE-2021-47602)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Make bnx2fc_recv_frame() mp safe\r\n\r\nRunning tests with a debug kernel shows that bnx2fc_recv_frame() is\nmodifying the per_cpu lport stats counters in a non-mpsafe way.  Just boot\na debug kernel and run the bnx2fc driver with the hardware enabled.\r\n\r\n[ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_\n[ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]\n[ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G    B\n[ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013\n[ 1391.699183] Call Trace:\n[ 1391.699188]  dump_stack_lvl+0x57/0x7d\n[ 1391.699198]  check_preemption_disabled+0xc8/0xd0\n[ 1391.699205]  bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]\n[ 1391.699215]  ? do_raw_spin_trylock+0xb5/0x180\n[ 1391.699221]  ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc]\n[ 1391.699229]  ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc]\n[ 1391.699240]  bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc]\n[ 1391.699250]  ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc]\n[ 1391.699258]  kthread+0x364/0x420\n[ 1391.699263]  ? _raw_spin_unlock_irq+0x24/0x50\n[ 1391.699268]  ? set_kthread_struct+0x100/0x100\n[ 1391.699273]  ret_from_fork+0x22/0x30\r\n\r\nRestore the old get_cpu/put_cpu code with some modifications to reduce the\nsize of the critical section.(CVE-2022-48715)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev\r\n\r\nstruct rpmsg_ctrldev contains a struct cdev. The current code frees\nthe rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the\ncdev is a managed object, therefore its release is not predictable\nand the rpmsg_ctrldev could be freed before the cdev is entirely\nreleased, as in the backtrace below.\r\n\r\n[   93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c\n[   93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0\n[   93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v\n[   93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G    B             5.4.163-lockdep #26\n[   93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)\n[   93.730055] Workqueue: events kobject_delayed_cleanup\n[   93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)\n[   93.740216] pc : debug_print_object+0x13c/0x1b0\n[   93.744890] lr : debug_print_object+0x13c/0x1b0\n[   93.749555] sp : ffffffacf5bc7940\n[   93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000\n[   93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000\n[   93.763916] x25: ffffffd0734f856c x24: dfffffd000000000\n[   93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0\n[   93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0\n[   93.780338] x19: ffffffd075199100 x18: 00000000000276e0\n[   93.785814] x17: 0000000000000000 x16: dfffffd000000000\n[   93.791291] x15: ffffffffffffffff x14: 6e6968207473696c\n[   93.796768] x13: 0000000000000000 x12: ffffffd075e2b000\n[   93.802244] x11: 0000000000000001 x10: 0000000000000000\n[   93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900\n[   93.813200] x7 : 0000000000000000 x6 : 0000000000000000\n[   93.818676] x5 : 0000000000000080 x4 : 0000000000000000\n[   93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001\n[   93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061\n[   93.835104] Call trace:\n[   93.837644]  debug_print_object+0x13c/0x1b0\n[   93.841963]  __debug_check_no_obj_freed+0x25c/0x3c0\n[   93.846987]  debug_check_no_obj_freed+0x18/0x20\n[   93.851669]  slab_free_freelist_hook+0xbc/0x1e4\n[   93.856346]  kfree+0xfc/0x2f4\n[   93.859416]  rpmsg_ctrldev_release_device+0x78/0xb8\n[   93.864445]  device_release+0x84/0x168\n[   93.868310]  kobject_cleanup+0x12c/0x298\n[   93.872356]  kobject_delayed_cleanup+0x10/0x18\n[   93.876948]  process_one_work+0x578/0x92c\n[   93.881086]  worker_thread+0x804/0xcf8\n[   93.884963]  kthread+0x2a8/0x314\n[   93.888303]  ret_from_fork+0x10/0x18\r\n\r\nThe cdev_device_add/del() API was created to address this issue (see\ncommit \u0026apos;233ed09d7fda (\u0026quot;chardev: add helper function to register char\ndevs with a struct device\u0026quot;)\u0026apos;), use it instead of cdev add/del().(CVE-2022-48759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet: fix rtm_phonet_notify() skb allocation\r\n\r\nfill_route() stores three components in the skb:\r\n\r\n- struct rtmsg\n- RTA_DST (u8)\n- RTA_OIF (u32)\r\n\r\nTherefore, rtm_phonet_notify() should use\r\n\r\nNLMSG_ALIGN(sizeof(struct rtmsg)) +\nnla_total_size(1) +\nnla_total_size(4)(CVE-2024-36946)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio: delete vq in vp_find_vqs_msix() when request_irq() fails\r\n\r\nWhen request_irq() fails, error path calls vp_del_vqs(). There, as vq is\npresent in the list, free_irq() is called for the same vector. That\ncauses following splat:\r\n\r\n[    0.414355] Trying to free already-free IRQ 27\n[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0\n[    0.414510] Modules linked in:\n[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27\n[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014\n[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0\n[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40\n[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086\n[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000\n[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001\n[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001\n[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760\n[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600\n[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000\n[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0\n[    0.414540] Call Trace:\n[    0.414540]  \u0026lt;TASK\u0026gt;\n[    0.414540]  ? __warn+0x80/0x120\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  ? report_bug+0x164/0x190\n[    0.414540]  ? handle_bug+0x3b/0x70\n[    0.414540]  ? exc_invalid_op+0x17/0x70\n[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  vp_del_vqs+0xc1/0x220\n[    0.414540]  vp_find_vqs_msix+0x305/0x470\n[    0.414540]  vp_find_vqs+0x3e/0x1a0\n[    0.414540]  vp_modern_find_vqs+0x1b/0x70\n[    0.414540]  init_vqs+0x387/0x600\n[    0.414540]  virtnet_probe+0x50a/0xc80\n[    0.414540]  virtio_dev_probe+0x1e0/0x2b0\n[    0.414540]  really_probe+0xc0/0x2c0\n[    0.414540]  ? __pfx___driver_attach+0x10/0x10\n[    0.414540]  __driver_probe_device+0x73/0x120\n[    0.414540]  driver_probe_device+0x1f/0xe0\n[    0.414540]  __driver_attach+0x88/0x180\n[    0.414540]  bus_for_each_dev+0x85/0xd0\n[    0.414540]  bus_add_driver+0xec/0x1f0\n[    0.414540]  driver_register+0x59/0x100\n[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10\n[    0.414540]  virtio_net_driver_init+0x90/0xb0\n[    0.414540]  do_one_initcall+0x58/0x230\n[    0.414540]  kernel_init_freeable+0x1a3/0x2d0\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  kernel_init+0x1a/0x1c0\n[    0.414540]  ret_from_fork+0x31/0x50\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  ret_from_fork_asm+0x1a/0x30\n[    0.414540]  \u0026lt;/TASK\u0026gt;\r\n\r\nFix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/mediatek: Add 0 size check to mtk_drm_gem_obj\r\n\r\nAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM object\nof 0 bytes. Currently, no such check exists and the kernel will panic if\na userspace application attempts to allocate a 0x0 GBM buffer.\r\n\r\nTested by attempting to allocate a 0x0 GBM buffer on an MT8188 and\nverifying that we now return EINVAL.(CVE-2024-38549)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bfa: Ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul instead\nof memdup_user.(CVE-2024-38560)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspeakup: Fix sizeof() vs ARRAY_SIZE() bug\r\n\r\nThe \u0026quot;buf\u0026quot; pointer is an array of u16 values.  This code should be\nusing ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),\notherwise it can the still got out of bounds.(CVE-2024-38587)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njffs2: prevent xattr node from overflowing the eraseblock\r\n\r\nAdd a check to make sure that the requested xattr node size is no larger\nthan the eraseblock minus the cleanmarker.\r\n\r\nUnlike the usual inode nodes, the xattr nodes aren\u0026apos;t split into parts\nand spread across multiple eraseblocks, which means that a xattr node\nmust not occupy more than one eraseblock. If the requested xattr value is\ntoo large, the xattr node can spill onto the next eraseblock, overwriting\nthe nodes and causing errors such as:\r\n\r\njffs2: argh. node added in wrong place at 0x0000b050(2)\njffs2: nextblock 0x0000a000, expected at 0000b00c\njffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,\nread=0xfc892c93, calc=0x000000\njffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed\nat 0x01e00c. {848f,2fc4,0fef511f,59a3d171}\njffs2: Node at 0x0000000c with length 0x00001044 would run over the\nend of the erase block\njffs2: Perhaps the file system was created with the wrong erase size?\njffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found\nat 0x00000010: 0x1044 instead\r\n\r\nThis breaks the filesystem and can lead to KASAN crashes such as:\r\n\r\nBUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0\nRead of size 4 at addr ffff88802c31e914 by task repro/830\nCPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS Arch Linux 1.16.3-1-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xc4/0x620\n ? __virt_addr_valid+0x308/0x5b0\n kasan_report+0xc1/0xf0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_flash_direct_writev+0xa8/0xd0\n jffs2_flash_writev+0x9c9/0xef0\n ? __x64_sys_setxattr+0xc4/0x160\n ? do_syscall_64+0x69/0x140\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nring-buffer: Fix a race between readers and resize checks\r\n\r\nThe reader code in rb_get_reader_page() swaps a new reader page into the\nring buffer by doing cmpxchg on old-\u0026gt;list.prev-\u0026gt;next to point it to the\nnew page. Following that, if the operation is successful,\nold-\u0026gt;list.next-\u0026gt;prev gets updated too. This means the underlying\ndoubly-linked list is temporarily inconsistent, page-\u0026gt;prev-\u0026gt;next or\npage-\u0026gt;next-\u0026gt;prev might not be equal back to page for some page in the\nring buffer.\r\n\r\nThe resize operation in ring_buffer_resize() can be invoked in parallel.\nIt calls rb_check_pages() which can detect the described inconsistency\nand stop further tracing:\r\n\r\n[  190.271762] ------------[ cut here ]------------\n[  190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0\n[  190.271789] Modules linked in: [...]\n[  190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1\n[  190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G            E      6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f\n[  190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014\n[  190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0\n[  190.272023] Code: [...]\n[  190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206\n[  190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80\n[  190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700\n[  190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000\n[  190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720\n[  190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000\n[  190.272053] FS:  00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000\n[  190.272057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0\n[  190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  190.272077] Call Trace:\n[  190.272098]  \u0026lt;TASK\u0026gt;\n[  190.272189]  ring_buffer_resize+0x2ab/0x460\n[  190.272199]  __tracing_resize_ring_buffer.part.0+0x23/0xa0\n[  190.272206]  tracing_resize_ring_buffer+0x65/0x90\n[  190.272216]  tracing_entries_write+0x74/0xc0\n[  190.272225]  vfs_write+0xf5/0x420\n[  190.272248]  ksys_write+0x67/0xe0\n[  190.272256]  do_syscall_64+0x82/0x170\n[  190.272363]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  190.272373] RIP: 0033:0x7f1bd657d263\n[  190.272381] Code: [...]\n[  190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[  190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263\n[  190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001\n[  190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000\n[  190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500\n[  190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002\n[  190.272412]  \u0026lt;/TASK\u0026gt;\n[  190.272414] ---[ end trace 0000000000000000 ]---\r\n\r\nNote that ring_buffer_resize() calls rb_check_pages() only if the parent\ntrace_buffer has recording disabled. Recent commit d78ab792705c\n(\u0026quot;tracing: Stop current tracer when resizing buffer\u0026quot;) causes that it is\nnow always the case which makes it more likely to experience this issue.\r\n\r\nThe window to hit this race is nonetheless very small. To help\nreproducing it, one can add a delay loop in rb_get_reader_page():\r\n\r\n ret = rb_head_page_replace(reader, cpu_buffer-\u0026gt;reader_page);\n if (!ret)\n \tgoto spin;\n for (unsigned i = 0; i \u0026lt; 1U \u0026lt;\u0026lt; 26; i++)  /* inserted delay loop */\n \t__asm__ __volatile__ (\u0026quot;\u0026quot; : : : \u0026quot;memory\u0026quot;);\n rb_list_head(reader-\u0026gt;list.next)-\u0026gt;prev = \u0026amp;cpu_buffer-\u0026gt;reader_page-\u0026gt;list;\r\n\r\n.. \n---truncated---(CVE-2024-38601)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nm68k: Fix spinlock race in kernel thread creation\r\n\r\nContext switching does take care to retain the correct lock owner across\nthe switch from \u0026apos;prev\u0026apos; to \u0026apos;next\u0026apos; tasks.  This does rely on interrupts\nremaining disabled for the entire duration of the switch.\r\n\r\nThis condition is guaranteed for normal process creation and context\nswitching between already running processes, because both \u0026apos;prev\u0026apos; and\n\u0026apos;next\u0026apos; already have interrupts disabled in their saved copies of the\nstatus register.\r\n\r\nThe situation is different for newly created kernel threads.  The status\nregister is set to PS_S in copy_thread(), which does leave the IPL at 0.\nUpon restoring the \u0026apos;next\u0026apos; thread\u0026apos;s status register in switch_to() aka\nresume(), interrupts then become enabled prematurely.  resume() then\nreturns via ret_from_kernel_thread() and schedule_tail() where run queue\nlock is released (see finish_task_switch() and finish_lock_switch()).\r\n\r\nA timer interrupt calling scheduler_tick() before the lock is released\nin finish_task_switch() will find the lock already taken, with the\ncurrent task as lock owner.  This causes a spinlock recursion warning as\nreported by Guenter Roeck.\r\n\r\nAs far as I can ascertain, this race has been opened in commit\n533e6903bea0 (\u0026quot;m68k: split ret_from_fork(), simplify kernel_thread()\u0026quot;)\nbut I haven\u0026apos;t done a detailed study of kernel history so it may well\npredate that commit.\r\n\r\nInterrupts cannot be disabled in the saved status register copy for\nkernel threads (init will complain about interrupts disabled when\nfinally starting user space).  Disable interrupts temporarily when\nswitching the tasks\u0026apos; register sets in resume().\r\n\r\nNote that a simple oriw 0x700,%sr after restoring sr is not enough here\n- this leaves enough of a race for the \u0026apos;spinlock recursion\u0026apos; warning to\nstill be observed.\r\n\r\nTested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: stk1160: fix bounds checking in stk1160_copy_video()\r\n\r\nThe subtract in this condition is reversed.  The -\u0026gt;length is the length\nof the buffer.  The -\u0026gt;bytesused is how many bytes we have copied thus\nfar.  When the condition is reversed that means the result of the\nsubtraction is always negative but since it\u0026apos;s unsigned then the result\nis a very high positive value.  That means the overflow check is never\ntrue.\r\n\r\nAdditionally, the -\u0026gt;bytesused doesn\u0026apos;t actually work for this purpose\nbecause we\u0026apos;re not writing to \u0026quot;buf-\u0026gt;mem + buf-\u0026gt;bytesused\u0026quot;.  Instead, the\nmath to calculate the destination where we are writing is a bit\ninvolved.  You calculate the number of full lines already written,\nmultiply by two, skip a line if necessary so that we start on an odd\nnumbered line, and add the offset into the line.\r\n\r\nTo fix this buffer overflow, just take the actual destination where we\nare writing, if the offset is already out of bounds print an error and\nreturn.  Otherwise, write up to buf-\u0026gt;length bytes.(CVE-2024-38621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger\r\n\r\nWhen the cpu5wdt module is removing, the origin code uses del_timer() to\nde-activate the timer. If the timer handler is running, del_timer() could\nnot stop it and will return directly. If the port region is released by\nrelease_region() and then the timer handler cpu5wdt_trigger() calls outb()\nto write into the region that is released, the use-after-free bug will\nhappen.\r\n\r\nChange del_timer() to timer_shutdown_sync() in order that the timer handler\ncould be finished before the port region is released.(CVE-2024-38630)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/ap: Fix crash in AP internal function modify_bitmap()\r\n\r\nA system crash like this\r\n\r\n  Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403\n  Fault in home space mode while using kernel ASCE.\n  AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d\n  Oops: 0038 ilc:3 [#1] PREEMPT SMP\n  Modules linked in: mlx5_ib ...\n  CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8\n  Hardware name: IBM 3931 A01 704 (LPAR)\n  Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)\n  R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3\n  Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3\n  000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0\n  000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff\n  000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8\n  Krnl Code: 0000014b75e7b5fc: a7840047            brc     8,0000014b75e7b68a\n  0000014b75e7b600: 18b2                lr      %r11,%r2\n  #0000014b75e7b602: a7f4000a            brc     15,0000014b75e7b616\n  \u0026gt;0000014b75e7b606: eb22d00000e6        laog    %r2,%r2,0(%r13)\n  0000014b75e7b60c: a7680001            lhi     %r6,1\n  0000014b75e7b610: 187b                lr      %r7,%r11\n  0000014b75e7b612: 84960021            brxh    %r9,%r6,0000014b75e7b654\n  0000014b75e7b616: 18e9                lr      %r14,%r9\n  Call Trace:\n  [\u0026lt;0000014b75e7b606\u0026gt;] ap_parse_bitmap_str+0x10e/0x1f8\n  ([\u0026lt;0000014b75e7b5dc\u0026gt;] ap_parse_bitmap_str+0xe4/0x1f8)\n  [\u0026lt;0000014b75e7b758\u0026gt;] apmask_store+0x68/0x140\n  [\u0026lt;0000014b75679196\u0026gt;] kernfs_fop_write_iter+0x14e/0x1e8\n  [\u0026lt;0000014b75598524\u0026gt;] vfs_write+0x1b4/0x448\n  [\u0026lt;0000014b7559894c\u0026gt;] ksys_write+0x74/0x100\n  [\u0026lt;0000014b7618a440\u0026gt;] __do_syscall+0x268/0x328\n  [\u0026lt;0000014b761a3558\u0026gt;] system_call+0x70/0x98\n  INFO: lockdep is turned off.\n  Last Breaking-Event-Address:\n  [\u0026lt;0000014b75e7b636\u0026gt;] ap_parse_bitmap_str+0x13e/0x1f8\n  Kernel panic - not syncing: Fatal exception: panic_on_oops\r\n\r\noccured when /sys/bus/ap/a[pq]mask was updated with a relative mask value\n(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.\r\n\r\nThe fix is simple: use unsigned long values for the internal variables. The\ncorrect checks are already in place in the function but a simple int for\nthe internal variables was used with the possibility to overflow.(CVE-2024-38661)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: Add winch to winch_handlers before registering winch IRQ\r\n\r\nRegistering a winch IRQ is racy, an interrupt may occur before the winch is\nadded to the winch_handlers list.\r\n\r\nIf that happens, register_winch_irq() adds to that list a winch that is\nscheduled to be (or has already been) freed, causing a panic later in\nwinch_cleanup().\r\n\r\nAvoid the race by adding the winch to the winch_handlers list before\nregistering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)",
  "id": "OESA-2024-1793",
  "modified": "2026-08-06T11:07:15Z",
  "published": "2024-07-05T11:07:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1793"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47235"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47285"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47602"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48715"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48759"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36946"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37353"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38549"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38560"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38587"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38599"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38601"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38613"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38630"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38661"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39292"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47235",
    "CVE-2021-47285",
    "CVE-2021-47602",
    "CVE-2022-48715",
    "CVE-2022-48759",
    "CVE-2024-36946",
    "CVE-2024-37353",
    "CVE-2024-38549",
    "CVE-2024-38560",
    "CVE-2024-38587",
    "CVE-2024-38599",
    "CVE-2024-38601",
    "CVE-2024-38613",
    "CVE-2024-38621",
    "CVE-2024-38630",
    "CVE-2024-38661",
    "CVE-2024-39292"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "kernel-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "perf-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-33.0.0.40.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-33.0.0.40.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-33.0.0.40.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "kernel-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "perf-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-33.0.0.40.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-33.0.0.40.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-33.0.0.40.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: lgdt3306a: Add a check against null-pointer-def\r\n\r\nThe driver should check whether the client provides the platform_data.\r\n\r\nThe following log reveals it:\r\n\r\n[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40\n[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414\n[   29.612820] Call Trace:\n[   29.613030]  \u0026lt;TASK\u0026gt;\n[   29.613201]  dump_stack_lvl+0x56/0x6f\n[   29.613496]  ? kmemdup+0x30/0x40\n[   29.613754]  print_report.cold+0x494/0x6b7\n[   29.614082]  ? kmemdup+0x30/0x40\n[   29.614340]  kasan_report+0x8a/0x190\n[   29.614628]  ? kmemdup+0x30/0x40\n[   29.614888]  kasan_check_range+0x14d/0x1d0\n[   29.615213]  memcpy+0x20/0x60\n[   29.615454]  kmemdup+0x30/0x40\n[   29.615700]  lgdt3306a_probe+0x52/0x310\n[   29.616339]  i2c_device_probe+0x951/0xa90(CVE-2022-48772)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngenirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline\r\n\r\nThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of\ninterrupt affinity reconfiguration via procfs. Instead, the change is\ndeferred until the next instance of the interrupt being triggered on the\noriginal CPU.\r\n\r\nWhen the interrupt next triggers on the original CPU, the new affinity is\nenforced within __irq_move_irq(). A vector is allocated from the new CPU,\nbut the old vector on the original CPU remains and is not immediately\nreclaimed. Instead, apicd-\u0026gt;move_in_progress is flagged, and the reclaiming\nprocess is delayed until the next trigger of the interrupt on the new CPU.\r\n\r\nUpon the subsequent triggering of the interrupt on the new CPU,\nirq_complete_move() adds a task to the old CPU\u0026apos;s vector_cleanup list if it\nremains online. Subsequently, the timer on the old CPU iterates over its\nvector_cleanup list, reclaiming old vectors.\r\n\r\nHowever, a rare scenario arises if the old CPU is outgoing before the\ninterrupt triggers again on the new CPU.\r\n\r\nIn that case irq_force_complete_move() is not invoked on the outgoing CPU\nto reclaim the old apicd-\u0026gt;prev_vector because the interrupt isn\u0026apos;t currently\naffine to the outgoing CPU, and irq_needs_fixup() returns false. Even\nthough __vector_schedule_cleanup() is later called on the new CPU, it\ndoesn\u0026apos;t reclaim apicd-\u0026gt;prev_vector; instead, it simply resets both\napicd-\u0026gt;move_in_progress and apicd-\u0026gt;prev_vector to 0.\r\n\r\nAs a result, the vector remains unreclaimed in vector_matrix, leading to a\nCPU vector leak.\r\n\r\nTo address this issue, move the invocation of irq_force_complete_move()\nbefore the irq_needs_fixup() call to reclaim apicd-\u0026gt;prev_vector, if the\ninterrupt is currently or used to be affine to the outgoing CPU.\r\n\r\nAdditionally, reclaim the vector in __vector_schedule_cleanup() as well,\nfollowing a warning message, although theoretically it should never see\napicd-\u0026gt;move_in_progress with apicd-\u0026gt;prev_cpu pointing to an offline CPU.(CVE-2024-31076)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntls: fix missing memory barrier in tls_init\r\n\r\nIn tls_init(), a write memory barrier is missing, and store-store\nreordering may cause NULL dereference in tls_{setsockopt,getsockopt}.\r\n\r\nCPU0                               CPU1\n-----                              -----\n// In tls_init()\n// In tls_ctx_create()\nctx = kzalloc()\nctx-\u0026gt;sk_proto = READ_ONCE(sk-\u0026gt;sk_prot) -(1)\r\n\r\n// In update_sk_prot()\nWRITE_ONCE(sk-\u0026gt;sk_prot, tls_prots)     -(2)\r\n\r\n                                   // In sock_common_setsockopt()\n                                   READ_ONCE(sk-\u0026gt;sk_prot)-\u0026gt;setsockopt()\r\n\r\n                                   // In tls_{setsockopt,getsockopt}()\n                                   ctx-\u0026gt;sk_proto-\u0026gt;setsockopt()    -(3)\r\n\r\nIn the above scenario, when (1) and (2) are reordered, (3) can observe\nthe NULL value of ctx-\u0026gt;sk_proto, causing NULL dereference.\r\n\r\nTo fix it, we rely on rcu_assign_pointer() which implies the release\nbarrier semantic. By moving rcu_assign_pointer() after ctx-\u0026gt;sk_proto is\ninitialized, we can ensure that ctx-\u0026gt;sk_proto are visible when\nchanging sk-\u0026gt;sk_prot.(CVE-2024-36489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\namd/amdkfd: sync all devices to wait all processes being evicted\r\n\r\nIf there are more than one device doing reset in parallel, the first\ndevice will call kfd_suspend_all_processes() to evict all processes\non all devices, this call takes time to finish. other device will\nstart reset and recover without waiting. if the process has not been\nevicted before doing recover, it will be restored, then caused page\nfault.(CVE-2024-36949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Move NPIV\u0026apos;s transport unregistration to after resource clean up\r\n\r\nThere are cases after NPIV deletion where the fabric switch still believes\nthe NPIV is logged into the fabric.  This occurs when a vport is\nunregistered before the Remove All DA_ID CT and LOGO ELS are sent to the\nfabric.\r\n\r\nCurrently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including\nthe fabric D_ID, removes the last ndlp reference and frees the ndlp rport\nobject.  This sometimes causes the race condition where the final DA_ID and\nLOGO are skipped from being sent to the fabric switch.\r\n\r\nFix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID\nand LOGO are sent.(CVE-2024-36952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ks8851: Queue RX packets in IRQ handler instead of disabling BHs\r\n\r\nCurrently the driver uses local_bh_disable()/local_bh_enable() in its\nIRQ handler to avoid triggering net_rx_action() softirq on exit from\nnetif_rx(). The net_rx_action() could trigger this driver .start_xmit\ncallback, which is protected by the same lock as the IRQ handler, so\ncalling the .start_xmit from netif_rx() from the IRQ handler critical\nsection protected by the lock could lead to an attempt to claim the\nalready claimed lock, and a hang.\r\n\r\nThe local_bh_disable()/local_bh_enable() approach works only in case\nthe IRQ handler is protected by a spinlock, but does not work if the\nIRQ handler is protected by mutex, i.e. this works for KS8851 with\nParallel bus interface, but not for KS8851 with SPI bus interface.\r\n\r\nRemove the BH manipulation and instead of calling netif_rx() inside\nthe IRQ handler code protected by the lock, queue all the received\nSKBs in the IRQ handler into a queue first, and once the IRQ handler\nexits the critical section protected by the lock, dequeue all the\nqueued SKBs and push them all into netif_rx(). At this point, it is\nsafe to trigger the net_rx_action() softirq, since the netif_rx()\ncall is outside of the lock that protects the IRQ handler.(CVE-2024-36962)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nremoteproc: mediatek: Make sure IPI buffer fits in L2TCM\r\n\r\nThe IPI buffer location is read from the firmware that we load to the\nSystem Companion Processor, and it\u0026apos;s not granted that both the SRAM\n(L2TCM) size that is defined in the devicetree node is large enough\nfor that, and while this is especially true for multi-core SCP, it\u0026apos;s\nstill useful to check on single-core variants as well.\r\n\r\nFailing to perform this check may make this driver perform R/W\noperations out of the L2TCM boundary, resulting (at best) in a\nkernel panic.\r\n\r\nTo fix that, check that the IPI buffer fits, otherwise return a\nfailure and refuse to boot the relevant SCP core (or the SCP at\nall, if this is single core).(CVE-2024-36965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio: delete vq in vp_find_vqs_msix() when request_irq() fails\r\n\r\nWhen request_irq() fails, error path calls vp_del_vqs(). There, as vq is\npresent in the list, free_irq() is called for the same vector. That\ncauses following splat:\r\n\r\n[    0.414355] Trying to free already-free IRQ 27\n[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0\n[    0.414510] Modules linked in:\n[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27\n[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014\n[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0\n[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40\n[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086\n[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000\n[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001\n[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001\n[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760\n[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600\n[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000\n[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0\n[    0.414540] Call Trace:\n[    0.414540]  \u0026lt;TASK\u0026gt;\n[    0.414540]  ? __warn+0x80/0x120\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  ? report_bug+0x164/0x190\n[    0.414540]  ? handle_bug+0x3b/0x70\n[    0.414540]  ? exc_invalid_op+0x17/0x70\n[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  vp_del_vqs+0xc1/0x220\n[    0.414540]  vp_find_vqs_msix+0x305/0x470\n[    0.414540]  vp_find_vqs+0x3e/0x1a0\n[    0.414540]  vp_modern_find_vqs+0x1b/0x70\n[    0.414540]  init_vqs+0x387/0x600\n[    0.414540]  virtnet_probe+0x50a/0xc80\n[    0.414540]  virtio_dev_probe+0x1e0/0x2b0\n[    0.414540]  really_probe+0xc0/0x2c0\n[    0.414540]  ? __pfx___driver_attach+0x10/0x10\n[    0.414540]  __driver_probe_device+0x73/0x120\n[    0.414540]  driver_probe_device+0x1f/0xe0\n[    0.414540]  __driver_attach+0x88/0x180\n[    0.414540]  bus_for_each_dev+0x85/0xd0\n[    0.414540]  bus_add_driver+0xec/0x1f0\n[    0.414540]  driver_register+0x59/0x100\n[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10\n[    0.414540]  virtio_net_driver_init+0x90/0xb0\n[    0.414540]  do_one_initcall+0x58/0x230\n[    0.414540]  kernel_init_freeable+0x1a3/0x2d0\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  kernel_init+0x1a/0x1c0\n[    0.414540]  ret_from_fork+0x31/0x50\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  ret_from_fork_asm+0x1a/0x30\n[    0.414540]  \u0026lt;/TASK\u0026gt;\r\n\r\nFix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix crash on racing fsync and size-extending write into prealloc\r\n\r\nWe have been seeing crashes on duplicate keys in\nbtrfs_set_item_key_safe():\r\n\r\n  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/ctree.c:2620!\n  invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\r\n\r\nWith the following stack trace:\r\n\r\n  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\n  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)\n  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)\n  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\n  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\n  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\n  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\n  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)\n  #8  vfs_fsync_range (fs/sync.c:188:9)\n  #9  vfs_fsync (fs/sync.c:202:9)\n  #10 do_fsync (fs/sync.c:212:9)\n  #11 __do_sys_fdatasync (fs/sync.c:225:9)\n  #12 __se_sys_fdatasync (fs/sync.c:223:1)\n  #13 __x64_sys_fdatasync (fs/sync.c:223:1)\n  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\n  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\n  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\r\n\r\nSo we\u0026apos;re logging a changed extent from fsync, which is splitting an\nextent in the log tree. But this split part already exists in the tree,\ntriggering the BUG().\r\n\r\nThis is the state of the log tree at the time of the crash, dumped with\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\nto get more details than btrfs_print_leaf() gives us:\r\n\r\n  \u0026gt;\u0026gt;\u0026gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0][\u0026quot;eb\u0026quot;])\n  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\n  leaf 33439744 flags 0x100000000000000\n  fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\n                  generation 7 transid 9 size 8192 nbytes 8473563889606862198\n                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n                  sequence 204 flags 0x10(PREALLOC)\n                  atime 1716417703.220000000 (2024-05-22 15:41:43)\n                  ctime 1716417704.983333333 (2024-05-22 15:41:44)\n                  mtime 1716417704.983333333 (2024-05-22 15:41:44)\n                  otime 17592186044416.000000000 (559444-03-08 01:40:16)\n          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\n                  index 195 namelen 3 name: 193\n          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\n                  location key (0 UNKNOWN.0 0) type XATTR\n                  transid 7 data_len 1 name_len 6\n                  name: user.a\n                  data a\n          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\n                  generation 9 type 1 (regular)\n                  extent data disk byte 303144960 nr 12288\n                  extent data offset 0 nr 4096 ram 12288\n                  extent compression 0 (none)\n          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 4096 nr 8192\n          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 8192 nr 4096\n  ...\r\n\r\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\nitem 5 starts at i_size.\r\n\r\nHere is the state of \n---truncated---(CVE-2024-37354)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: Fix shift-out-of-bounds in dctcp_update_alpha().\r\n\r\nIn dctcp_update_alpha(), we use a module parameter dctcp_shift_g\nas follows:\r\n\r\n  alpha -= min_not_zero(alpha, alpha \u0026gt;\u0026gt; dctcp_shift_g);\n  ...\n  delivered_ce \u0026lt;\u0026lt;= (10 - dctcp_shift_g);\r\n\r\nIt seems syzkaller started fuzzing module parameters and triggered\nshift-out-of-bounds [0] by setting 100 to dctcp_shift_g:\r\n\r\n  memcpy((void*)0x20000080,\n         \u0026quot;/sys/module/tcp_dctcp/parameters/dctcp_shift_g\\000\u0026quot;, 47);\n  res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,\n                /*flags=*/2ul, /*mode=*/0ul);\n  memcpy((void*)0x20000000, \u0026quot;100\\000\u0026quot;, 4);\n  syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);\r\n\r\nLet\u0026apos;s limit the max value of dctcp_shift_g by param_set_uint_minmax().\r\n\r\nWith this patch:\r\n\r\n  # echo 10 \u0026gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n  # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n  10\n  # echo 11 \u0026gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n  -bash: echo: write error: Invalid argument\r\n\r\n[0]:\nUBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12\nshift exponent 100 is too large for 32-bit type \u0026apos;u32\u0026apos; (aka \u0026apos;unsigned int\u0026apos;)\nCPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468\n dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143\n tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]\n tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948\n tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711\n tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937\n sk_backlog_rcv include/net/sock.h:1106 [inline]\n __release_sock+0x20f/0x350 net/core/sock.c:2983\n release_sock+0x61/0x1f0 net/core/sock.c:3549\n mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907\n mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976\n __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072\n mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127\n inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437\n __sock_release net/socket.c:659 [inline]\n sock_close+0xc0/0x240 net/socket.c:1421\n __fput+0x41b/0x890 fs/file_table.c:422\n task_work_run+0x23b/0x300 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x9c8/0x2540 kernel/exit.c:878\n do_group_exit+0x201/0x2b0 kernel/exit.c:1027\n __do_sys_exit_group kernel/exit.c:1038 [inline]\n __se_sys_exit_group kernel/exit.c:1036 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x67/0x6f\nRIP: 0033:0x7f6c2b5005b6\nCode: Unable to access opcode bytes at 0x7f6c2b50058c.\nRSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6\nRDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001\nRBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0\nR10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0\nR13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n \u0026lt;/TASK\u0026gt;(CVE-2024-37356)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: mediatek: Assign dummy when codec not specified for a DAI link\r\n\r\nMediaTek sound card drivers are checking whether a DAI link is present\nand used on a board to assign the correct parameters and this is done\nby checking the codec DAI names at probe time.\r\n\r\nIf no real codec is present, assign the dummy codec to the DAI link\nto avoid NULL pointer during string comparison.(CVE-2024-38551)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential index out of bounds in color transformation function\r\n\r\nFixes index out of bounds issue in the color transformation function.\nThe issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer\nfunction points (TRANSFER_FUNC_POINTS).\r\n\r\nThe fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the\ntransfer function points. If \u0026apos;i\u0026apos; is out of bounds, an error message is\nlogged and the function returns false to indicate an error.\r\n\r\nReported by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-38552)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issue of net_device\r\n\r\nThere is a reference count leak issue of the object \u0026quot;net_device\u0026quot; in\nax25_dev_device_down(). When the ax25 device is shutting down, the\nax25_dev_device_down() drops the reference count of net_device one\nor zero times depending on if we goto unlock_put or not, which will\ncause memory leak.\r\n\r\nIn order to solve the above issue, decrease the reference count of\nnet_device after dev-\u0026gt;ax25_ptr is set to null.(CVE-2024-38554)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Discard command completions in internal error\r\n\r\nFix use after free when FW completion arrives while device is in\ninternal error state. Avoid calling completion handler in this case,\nsince the device will flush the command interface and trigger all\ncompletions manually.\r\n\r\nKernel log:\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\n...\nRIP: 0010:refcount_warn_saturate+0xd8/0xe0\n...\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n? __warn+0x79/0x120\n? refcount_warn_saturate+0xd8/0xe0\n? report_bug+0x17c/0x190\n? handle_bug+0x3c/0x60\n? exc_invalid_op+0x14/0x70\n? asm_exc_invalid_op+0x16/0x20\n? refcount_warn_saturate+0xd8/0xe0\ncmd_ent_put+0x13b/0x160 [mlx5_core]\nmlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]\ncmd_comp_notifier+0x1f/0x30 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nmlx5_eq_async_int+0xf6/0x290 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nirq_int_handler+0x19/0x30 [mlx5_core]\n__handle_irq_event_percpu+0x4b/0x160\nhandle_irq_event+0x2e/0x80\nhandle_edge_irq+0x98/0x230\n__common_interrupt+0x3b/0xa0\ncommon_interrupt+0x7b/0xa0\n\u0026lt;/IRQ\u0026gt;\n\u0026lt;TASK\u0026gt;\nasm_common_interrupt+0x22/0x40(CVE-2024-38555)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: nl80211: Avoid address calculations via out of bounds array indexing\r\n\r\nBefore request-\u0026gt;channels[] can be used, request-\u0026gt;n_channels must be set.\nAdditionally, address calculations for memory after the \u0026quot;channels\u0026quot; array\nneed to be calculated from the allocation base (\u0026quot;request\u0026quot;) rather than\nvia the first \u0026quot;out of bounds\u0026quot; index of \u0026quot;channels\u0026quot;, otherwise run-time\nbounds checking will throw a warning.(CVE-2024-38562)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE\r\n\r\nbpf_prog_attach uses attach_type_to_prog_type to enforce proper\nattach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses\nbpf_prog_get and relies on bpf_prog_attach_check_attach_type\nto properly verify prog_type \u0026lt;\u0026gt; attach_type association.\r\n\r\nAdd missing attach_type enforcement for the link_create case.\nOtherwise, it\u0026apos;s currently possible to attach cgroup_skb prog\ntypes to other cgroup hooks.(CVE-2024-38564)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow\r\n\r\nThere is a possibility of buffer overflow in\nshow_rcu_tasks_trace_gp_kthread() if counters, passed\nto sprintf() are huge. Counter numbers, needed for this\nare unrealistically high, but buffer overflow is still\npossible.\r\n\r\nUse snprintf() with buffer size instead of sprintf().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38577)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: bcm - Fix pointer arithmetic\r\n\r\nIn spu2_dump_omd() value of ptr is increased by ciph_key_len\ninstead of hash_iv_len which could lead to going beyond the\nbuffer boundaries.\nFix this bug by changing ciph_key_len to hash_iv_len.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential hang in nilfs_detach_log_writer()\r\n\r\nSyzbot has reported a potential hang in nilfs_detach_log_writer() called\nduring nilfs2 unmount.\r\n\r\nAnalysis revealed that this is because nilfs_segctor_sync(), which\nsynchronizes with the log writer thread, can be called after\nnilfs_segctor_destroy() terminates that thread, as shown in the call trace\nbelow:\r\n\r\nnilfs_detach_log_writer\n  nilfs_segctor_destroy\n    nilfs_segctor_kill_thread  --\u0026gt; Shut down log writer thread\n    flush_work\n      nilfs_iput_work_func\n        nilfs_dispose_list\n          iput\n            nilfs_evict_inode\n              nilfs_transaction_commit\n                nilfs_construct_segment (if inode needs sync)\n                  nilfs_segctor_sync  --\u0026gt; Attempt to synchronize with\n                                          log writer thread\n                           *** DEADLOCK ***\r\n\r\nFix this issue by changing nilfs_segctor_sync() so that the log writer\nthread returns normally without synchronizing after it terminates, and by\nforcing tasks that are already waiting to complete once after the thread\nterminates.\r\n\r\nThe skipped inode metadata flushout will then be processed together in the\nsubsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nftrace: Fix possible use-after-free issue in ftrace_location()\r\n\r\nKASAN reports a bug:\r\n\r\n  BUG: KASAN: use-after-free in ftrace_location+0x90/0x120\n  Read of size 8 at addr ffff888141d40010 by task insmod/424\n  CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+\n  [...]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x68/0xa0\n   print_report+0xcf/0x610\n   kasan_report+0xb5/0xe0\n   ftrace_location+0x90/0x120\n   register_kprobe+0x14b/0xa40\n   kprobe_init+0x2d/0xff0 [kprobe_example]\n   do_one_initcall+0x8f/0x2d0\n   do_init_module+0x13a/0x3c0\n   load_module+0x3082/0x33d0\n   init_module_from_file+0xd2/0x130\n   __x64_sys_finit_module+0x306/0x440\n   do_syscall_64+0x68/0x140\n   entry_SYSCALL_64_after_hwframe+0x71/0x79\r\n\r\nThe root cause is that, in lookup_rec(), ftrace record of some address\nis being searched in ftrace pages of some module, but those ftrace pages\nat the same time is being freed in ftrace_release_mod() as the\ncorresponding module is being deleted:\r\n\r\n           CPU1                       |      CPU2\n  register_kprobes() {                | delete_module() {\n    check_kprobe_address_safe() {     |\n      arch_check_ftrace_location() {  |\n        ftrace_location() {           |\n          lookup_rec() // USE!        |   ftrace_release_mod() // Free!\r\n\r\nTo fix this issue:\n  1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();\n  2. Use ftrace_location_range() instead of lookup_rec() in\n     ftrace_location();\n  3. Call synchronize_rcu() before freeing any ftrace pages both in\n     ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().(CVE-2024-38588)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix resync softlockup when bitmap size is less than array size\r\n\r\nIs is reported that for dm-raid10, lvextend + lvchange --syncaction will\ntrigger following softlockup:\r\n\r\nkernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]\nCPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1\nRIP: 0010:_raw_spin_unlock_irq+0x13/0x30\nCall Trace:\n \u0026lt;TASK\u0026gt;\n md_bitmap_start_sync+0x6b/0xf0\n raid10_sync_request+0x25c/0x1b40 [raid10]\n md_do_sync+0x64b/0x1020\n md_thread+0xa7/0x170\n kthread+0xcf/0x100\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1a/0x30\r\n\r\nAnd the detailed process is as follows:\r\n\r\nmd_do_sync\n j = mddev-\u0026gt;resync_min\n while (j \u0026lt; max_sectors)\n  sectors = raid10_sync_request(mddev, j, \u0026amp;skipped)\n   if (!md_bitmap_start_sync(..., \u0026amp;sync_blocks))\n    // md_bitmap_start_sync set sync_blocks to 0\n    return sync_blocks + sectors_skippe;\n  // sectors = 0;\n  j += sectors;\n  // j never change\r\n\r\nRoot cause is that commit 301867b1c168 (\u0026quot;md/raid10: check\nslab-out-of-bounds in md_bitmap_get_counter\u0026quot;) return early from\nmd_bitmap_get_counter(), without setting returned blocks.\r\n\r\nFix this problem by always set returned blocks from\nmd_bitmap_get_counter\u0026quot;(), as it used to be.\r\n\r\nNoted that this patch just fix the softlockup problem in kernel, the\ncase that bitmap size doesn\u0026apos;t match array size still need to be fixed.(CVE-2024-38598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njffs2: prevent xattr node from overflowing the eraseblock\r\n\r\nAdd a check to make sure that the requested xattr node size is no larger\nthan the eraseblock minus the cleanmarker.\r\n\r\nUnlike the usual inode nodes, the xattr nodes aren\u0026apos;t split into parts\nand spread across multiple eraseblocks, which means that a xattr node\nmust not occupy more than one eraseblock. If the requested xattr value is\ntoo large, the xattr node can spill onto the next eraseblock, overwriting\nthe nodes and causing errors such as:\r\n\r\njffs2: argh. node added in wrong place at 0x0000b050(2)\njffs2: nextblock 0x0000a000, expected at 0000b00c\njffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,\nread=0xfc892c93, calc=0x000000\njffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed\nat 0x01e00c. {848f,2fc4,0fef511f,59a3d171}\njffs2: Node at 0x0000000c with length 0x00001044 would run over the\nend of the erase block\njffs2: Perhaps the file system was created with the wrong erase size?\njffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found\nat 0x00000010: 0x1044 instead\r\n\r\nThis breaks the filesystem and can lead to KASAN crashes such as:\r\n\r\nBUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0\nRead of size 4 at addr ffff88802c31e914 by task repro/830\nCPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS Arch Linux 1.16.3-1-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xc4/0x620\n ? __virt_addr_valid+0x308/0x5b0\n kasan_report+0xc1/0xf0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_flash_direct_writev+0xa8/0xd0\n jffs2_flash_writev+0x9c9/0xef0\n ? __x64_sys_setxattr+0xc4/0x160\n ? do_syscall_64+0x69/0x140\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issues of ax25_dev\r\n\r\nThe ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference\ncount leak issue of the object \u0026quot;ax25_dev\u0026quot;.\r\n\r\nMemory leak issue in ax25_addr_ax25dev():\r\n\r\nThe reference count of the object \u0026quot;ax25_dev\u0026quot; can be increased multiple\ntimes in ax25_addr_ax25dev(). This will cause a memory leak.\r\n\r\nMemory leak issues in ax25_dev_device_down():\r\n\r\nThe reference count of ax25_dev is set to 1 in ax25_dev_device_up() and\nthen increase the reference count when ax25_dev is added to ax25_dev_list.\nAs a result, the reference count of ax25_dev is 2. But when the device is\nshutting down. The ax25_dev_device_down() drops the reference count once\nor twice depending on if we goto unlock_put or not, which will cause\nmemory leak.\r\n\r\nAs for the issue of ax25_addr_ax25dev(), it is impossible for one pointer\nto be on a list twice. So add a break in ax25_addr_ax25dev(). As for the\nissue of ax25_dev_device_down(), increase the reference count of ax25_dev\nonce in ax25_dev_device_up() and decrease the reference count of ax25_dev\nafter it is removed from the ax25_dev_list.(CVE-2024-38602)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: refine the EOF check in blkdev_iomap_begin\r\n\r\nblkdev_iomap_begin rounds down the offset to the logical block size\nbefore stashing it in iomap-\u0026gt;offset and checking that it still is\ninside the inode size.\r\n\r\nCheck the i_size check to the raw pos value so that we don\u0026apos;t try a\nzero size write if iter-\u0026gt;pos is unaligned.(CVE-2024-38604)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()\r\n\r\nPatch series \u0026quot;mm: follow_pte() improvements and acrn follow_pte() fixes\u0026quot;.\r\n\r\nPatch #1 fixes a bunch of issues I spotted in the acrn driver.  It\ncompiles, that\u0026apos;s all I know.  I\u0026apos;ll appreciate some review and testing from\nacrn folks.\r\n\r\nPatch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding\nmore sanity checks, and improving the documentation.  Gave it a quick test\non x86-64 using VM_PAT that ends up using follow_pte().\r\n\r\n\nThis patch (of 3):\r\n\r\nWe currently miss handling various cases, resulting in a dangerous\nfollow_pte() (previously follow_pfn()) usage.\r\n\r\n(1) We\u0026apos;re not checking PTE write permissions.\r\n\r\nMaybe we should simply always require pte_write() like we do for\npin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let\u0026apos;s check for\nACRN_MEM_ACCESS_WRITE for now.\r\n\r\n(2) We\u0026apos;re not rejecting refcounted pages.\r\n\r\nAs we are not using MMU notifiers, messing with refcounted pages is\ndangerous and can result in use-after-free. Let\u0026apos;s make sure to reject them.\r\n\r\n(3) We are only looking at the first PTE of a bigger range.\r\n\r\nWe only lookup a single PTE, but memmap-\u0026gt;len may span a larger area.\nLet\u0026apos;s loop over all involved PTEs and make sure the PFN range is\nactually contiguous. Reject everything else: it couldn\u0026apos;t have worked\neither way, and rather made use access PFNs we shouldn\u0026apos;t be accessing.(CVE-2024-38610)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dpu: Add callback function pointer check before its call\r\n\r\nIn dpu_core_irq_callback_handler() callback function pointer is compared to NULL,\nbut then callback function is unconditionally called by this pointer.\nFix this bug by adding conditional return.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\r\n\r\nPatchwork: https://patchwork.freedesktop.org/patch/588237/(CVE-2024-38622)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Use variable length array instead of fixed size\r\n\r\nShould fix smatch warning:\n\tntfs_set_label() error: __builtin_memcpy() \u0026apos;uni-\u0026gt;name\u0026apos; too small (20 vs 256)(CVE-2024-38623)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Use 64 bit variable to avoid 32 bit overflow\r\n\r\nFor example, in the expression:\n\tvbo = 2 * vbo + skip(CVE-2024-38624)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Check \u0026apos;folio\u0026apos; pointer for NULL\r\n\r\nIt can be NULL if bmap is called.(CVE-2024-38625)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.\r\n\r\nHang on to the control IDs instead of pointers since those are correctly\nhandled with locks.(CVE-2024-38628)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: idxd: Avoid unnecessary destruction of file_ida\r\n\r\nfile_ida is allocated during cdev open and is freed accordingly\nduring cdev release. This sequence is guaranteed by driver file\noperations. Therefore, there is no need to destroy an already empty\nfile_ida when the WQ cdev is removed.\r\n\r\nWorse, ida_free() in cdev release may happen after destruction of\nfile_ida per WQ cdev. This can lead to accessing an id in file_ida\nafter it has been destroyed, resulting in a kernel panic.\r\n\r\nRemove ida_destroy(\u0026amp;file_ida) to address these issues.(CVE-2024-38629)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger\r\n\r\nWhen the cpu5wdt module is removing, the origin code uses del_timer() to\nde-activate the timer. If the timer handler is running, del_timer() could\nnot stop it and will return directly. If the port region is released by\nrelease_region() and then the timer handler cpu5wdt_trigger() calls outb()\nto write into the region that is released, the use-after-free bug will\nhappen.\r\n\r\nChange del_timer() to timer_shutdown_sync() in order that the timer handler\ncould be finished before the port region is released.(CVE-2024-38630)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Lock port-\u0026gt;lock when calling uart_handle_cts_change()\r\n\r\nuart_handle_cts_change() has to be called with port lock taken,\nSince we run it in a separate work, the lock may not be taken at\nthe time of running. Make sure that it\u0026apos;s taken by explicitly doing\nthat. Without it we got a splat:\r\n\r\n  WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0\n  ...\n  Workqueue: max3100-0 max3100_work [max3100]\n  RIP: 0010:uart_handle_cts_change+0xa6/0xb0\n  ...\n   max3100_handlerx+0xc5/0x110 [max3100]\n   max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngreybus: lights: check return of get_channel_from_mode\r\n\r\nIf channel for the given node is not found we return null from\nget_channel_from_mode. Make sure we validate the return pointer\nbefore using it in two of the missing places.\r\n\r\nThis was originally reported in [0]:\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\r\n\r\n[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Allow delete from sockmap/sockhash only if update is allowed\r\n\r\nWe have seen an influx of syzkaller reports where a BPF program attached to\na tracepoint triggers a locking rule violation by performing a map_delete\non a sockmap/sockhash.\r\n\r\nWe don\u0026apos;t intend to support this artificial use scenario. Extend the\nexisting verifier allowed-program-type check for updating sockmap/sockhash\nto also cover deleting from a map.\r\n\r\nFrom now on only BPF programs which were previously allowed to update\nsockmap/sockhash can delete from these map types.(CVE-2024-38662)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: zynqmp_dpsub: Always register bridge\r\n\r\nWe must always register the DRM bridge, since zynqmp_dp_hpd_work_func\ncalls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be\ninitialized. We do this before zynqmp_dpsub_drm_init since that calls\ndrm_bridge_attach. This fixes the following lockdep warning:\r\n\r\n[   19.217084] ------------[ cut here ]------------\n[   19.227530] DEBUG_LOCKS_WARN_ON(lock-\u0026gt;magic != lock)\n[   19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550\n[   19.241696] Modules linked in:\n[   19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96\n[   19.252046] Hardware name: xlnx,zynqmp (DT)\n[   19.256421] Workqueue: events zynqmp_dp_hpd_work_func\n[   19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   19.269104] pc : __mutex_lock+0x4bc/0x550\n[   19.273364] lr : __mutex_lock+0x4bc/0x550\n[   19.277592] sp : ffffffc085c5bbe0\n[   19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8\n[   19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000\n[   19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000\n[   19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000\n[   19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720\n[   19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001\n[   19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888\n[   19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000\n[   19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000\n[   19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880\n[   19.356581] Call trace:\n[   19.359160]  __mutex_lock+0x4bc/0x550\n[   19.363032]  mutex_lock_nested+0x24/0x30\n[   19.367187]  drm_bridge_hpd_notify+0x2c/0x6c\n[   19.371698]  zynqmp_dp_hpd_work_func+0x44/0x54\n[   19.376364]  process_one_work+0x3ac/0x988\n[   19.380660]  worker_thread+0x398/0x694\n[   19.384736]  kthread+0x1bc/0x1c0\n[   19.388241]  ret_from_fork+0x10/0x20\n[   19.392031] irq event stamp: 183\n[   19.395450] hardirqs last  enabled at (183): [\u0026lt;ffffffc0800b9278\u0026gt;] finish_task_switch.isra.0+0xa8/0x2d4\n[   19.405140] hardirqs last disabled at (182): [\u0026lt;ffffffc081ad3754\u0026gt;] __schedule+0x714/0xd04\n[   19.413612] softirqs last  enabled at (114): [\u0026lt;ffffffc080133de8\u0026gt;] srcu_invoke_callbacks+0x158/0x23c\n[   19.423128] softirqs last disabled at (110): [\u0026lt;ffffffc080133de8\u0026gt;] srcu_invoke_callbacks+0x158/0x23c\n[   19.432614] ---[ end trace 0000000000000000 ]---\r\n\r\n(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)(CVE-2024-38664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-buf/sw-sync: don\u0026apos;t enable IRQ from sync_print_obj()\r\n\r\nSince commit a6aa8fca4d79 (\u0026quot;dma-buf/sw-sync: Reduce irqsave/irqrestore from\nknown context\u0026quot;) by error replaced spin_unlock_irqrestore() with\nspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite\nsync_print_obj() is called from sync_debugfs_show(), lockdep complains\ninconsistent lock state warning.\r\n\r\nUse plain spin_{lock,unlock}() for sync_print_obj(), for\nsync_debugfs_show() is already using spin_{lock,unlock}_irq().(CVE-2024-38780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: fix oops during rmmod\r\n\r\n\u0026quot;rmmod bonding\u0026quot; causes an oops ever since commit cc317ea3d927 (\u0026quot;bonding:\nremove redundant NULL check in debugfs function\u0026quot;).  Here are the relevant\nfunctions being called:\r\n\r\nbonding_exit()\n  bond_destroy_debugfs()\n    debugfs_remove_recursive(bonding_debug_root);\n    bonding_debug_root = NULL; \u0026lt;--------- SET TO NULL HERE\n  bond_netlink_fini()\n    rtnl_link_unregister()\n      __rtnl_link_unregister()\n        unregister_netdevice_many_notify()\n          bond_uninit()\n            bond_debug_unregister()\n              (commit removed check for bonding_debug_root == NULL)\n              debugfs_remove()\n              simple_recursive_removal()\n                down_write() -\u0026gt; OOPS\r\n\r\nHowever, reverting the bad commit does not solve the problem completely\nbecause the original code contains a race that could cause the same\noops, although it was much less likely to be triggered unintentionally:\r\n\r\nCPU1\n  rmmod bonding\n    bonding_exit()\n      bond_destroy_debugfs()\n        debugfs_remove_recursive(bonding_debug_root);\r\n\r\nCPU2\n  echo -bond0 \u0026gt; /sys/class/net/bonding_masters\n    bond_uninit()\n      bond_debug_unregister()\n        if (!bonding_debug_root)\r\n\r\nCPU1\n        bonding_debug_root = NULL;\r\n\r\nSo do NOT revert the bad commit (since the removed checks were racy\nanyway), and instead change the order of actions taken during module\nremoval.  The same oops can also happen if there is an error during\nmodule init, so apply the same fix there.(CVE-2024-39296)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/9p: fix uninit-value in p9_client_rpc()\r\n\r\nSyzbot with the help of KMSAN reported the following error:\r\n\r\nBUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]\nBUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n trace_9p_client_res include/trace/events/9p.h:146 [inline]\n p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2175 [inline]\n allocate_slab mm/slub.c:2338 [inline]\n new_slab+0x2de/0x1400 mm/slub.c:2391\n ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525\n __slab_alloc mm/slub.c:3610 [inline]\n __slab_alloc_node mm/slub.c:3663 [inline]\n slab_alloc_node mm/slub.c:3835 [inline]\n kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852\n p9_tag_alloc net/9p/client.c:278 [inline]\n p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641\n p9_client_rpc+0x27e/0x1340 net/9p/client.c:688\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nIf p9_check_errors() fails early in p9_client_rpc(), req-\u0026gt;rc.tag\nwill not be properly initialized. However, trace_9p_client_res()\nends up trying to print it out anyway before p9_client_rpc()\nfinishes.\r\n\r\nFix this issue by assigning default values to p9_fcall fields\nsuch as \u0026apos;tag\u0026apos; and (just in case KMSAN unearths something new) \u0026apos;id\u0026apos;\nduring the tag allocation stage.(CVE-2024-39301)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-39362)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: check for non-NULL file pointer in io_file_can_poll()\r\n\r\nIn earlier kernels, it was possible to trigger a NULL pointer\ndereference off the forced async preparation path, if no file had\nbeen assigned. The trace leading to that looks as follows:\r\n\r\nBUG: kernel NULL pointer dereference, address: 00000000000000b0\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022\nRIP: 0010:io_buffer_select+0xc3/0x210\nCode: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 \u0026lt;48\u0026gt; 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b\nRSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246\nRAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040\nRDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700\nRBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020\nR10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8\nR13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000\nFS:  00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x1f/0x60\n ? page_fault_oops+0x14d/0x420\n ? do_user_addr_fault+0x61/0x6a0\n ? exc_page_fault+0x6c/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? io_buffer_select+0xc3/0x210\n __io_import_iovec+0xb5/0x120\n io_readv_prep_async+0x36/0x70\n io_queue_sqe_fallback+0x20/0x260\n io_submit_sqes+0x314/0x630\n __do_sys_io_uring_enter+0x339/0xbc0\n ? __do_sys_io_uring_register+0x11b/0xc50\n ? vm_mmap_pgoff+0xce/0x160\n do_syscall_64+0x5f/0x180\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\nRIP: 0033:0x55e0a110a67e\nCode: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 \u0026lt;c3\u0026gt; 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6\r\n\r\nbecause the request is marked forced ASYNC and has a bad file fd, and\nhence takes the forced async prep path.\r\n\r\nCurrent kernels with the request async prep cleaned up can no longer hit\nthis issue, but for ease of backporting, let\u0026apos;s add this safety check in\nhere too as it really doesn\u0026apos;t hurt. For both cases, this will inevitably\nend with a CQE posted with -EBADF.(CVE-2024-39371)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: bcm: rpi: Assign -\u0026gt;num before accessing -\u0026gt;hws\r\n\r\nCommit f316cdff8d67 (\u0026quot;clk: Annotate struct clk_hw_onecell_data with\n__counted_by\u0026quot;) annotated the hws member of \u0026apos;struct clk_hw_onecell_data\u0026apos;\nwith __counted_by, which informs the bounds sanitizer about the number\nof elements in hws, so that it can warn when hws is accessed out of\nbounds. As noted in that change, the __counted_by member must be\ninitialized with the number of elements before the first array access\nhappens, otherwise there will be a warning from each access prior to the\ninitialization because the number of elements is zero. This occurs in\nraspberrypi_discover_clocks() due to -\u0026gt;num being assigned after -\u0026gt;hws\nhas been accessed:\r\n\r\n  UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4\n  index 3 is out of range for type \u0026apos;struct clk_hw *[] __counted_by(num)\u0026apos; (aka \u0026apos;struct clk_hw *[]\u0026apos;)\r\n\r\nMove the -\u0026gt;num initialization to before the first access of -\u0026gt;hws, which\nclears up the warning.(CVE-2024-39461)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal/drivers/qcom/lmh: Check for SCM availability at probe\r\n\r\nUp until now, the necessary scm availability check has not been\nperformed, leading to possible null pointer dereferences (which did\nhappen for me on RB1).\r\n\r\nFix that.(CVE-2024-39466)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()\r\n\r\nsyzbot reports a kernel bug as below:\r\n\r\nF2FS-fs (loop0): Mounted with checkpoint version = 48b305e4\n==================================================================\nBUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\nBUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]\nBUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\nRead of size 1 at addr ffff88807a58c76c by task syz-executor280/5076\r\n\r\nCPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\n current_nat_addr fs/f2fs/node.h:213 [inline]\n f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\n f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]\n f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925\n ioctl_fiemap fs/ioctl.c:220 [inline]\n do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838\n __do_sys_ioctl fs/ioctl.c:902 [inline]\n __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nThe root cause is we missed to do sanity check on i_xattr_nid during\nf2fs_iget(), so that in fiemap() path, current_nat_addr() will access\nnat_bitmap w/ offset from invalid i_xattr_nid, result in triggering\nkasan bug report, fix it.(CVE-2024-39467)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix deadlock in smb2_find_smb_tcon()\r\n\r\nUnlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such\ndeadlock.(CVE-2024-39468)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neventfs: Fix a possible null pointer dereference in eventfs_find_events()\r\n\r\nIn function eventfs_find_events,there is a potential null pointer\nthat may be caused by calling update_events_attr which will perform\nsome operations on the members of the ei struct when ei is NULL.\r\n\r\nHence,When ei-\u0026gt;is_freed is set,return NULL directly.(CVE-2024-39470)",
  "id": "OESA-2024-1836",
  "modified": "2026-08-06T11:07:18Z",
  "published": "2024-07-12T11:07:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1836"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48772"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31076"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36489"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36949"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36962"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37353"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37354"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37356"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38551"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38552"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38554"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38555"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38562"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38564"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38577"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38579"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38582"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38588"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38598"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38599"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38602"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38604"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38610"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38622"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38623"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38624"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38625"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38628"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38629"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38630"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38634"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38637"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38662"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38664"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39296"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39362"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39371"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39461"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39466"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39467"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39468"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39470"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48772",
    "CVE-2024-31076",
    "CVE-2024-36489",
    "CVE-2024-36949",
    "CVE-2024-36952",
    "CVE-2024-36962",
    "CVE-2024-36965",
    "CVE-2024-37353",
    "CVE-2024-37354",
    "CVE-2024-37356",
    "CVE-2024-38551",
    "CVE-2024-38552",
    "CVE-2024-38554",
    "CVE-2024-38555",
    "CVE-2024-38562",
    "CVE-2024-38564",
    "CVE-2024-38577",
    "CVE-2024-38579",
    "CVE-2024-38582",
    "CVE-2024-38588",
    "CVE-2024-38598",
    "CVE-2024-38599",
    "CVE-2024-38602",
    "CVE-2024-38604",
    "CVE-2024-38610",
    "CVE-2024-38622",
    "CVE-2024-38623",
    "CVE-2024-38624",
    "CVE-2024-38625",
    "CVE-2024-38628",
    "CVE-2024-38629",
    "CVE-2024-38630",
    "CVE-2024-38634",
    "CVE-2024-38637",
    "CVE-2024-38662",
    "CVE-2024-38664",
    "CVE-2024-38780",
    "CVE-2024-39296",
    "CVE-2024-39301",
    "CVE-2024-39362",
    "CVE-2024-39371",
    "CVE-2024-39461",
    "CVE-2024-39466",
    "CVE-2024-39467",
    "CVE-2024-39468",
    "CVE-2024-39470"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.84.0.165.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.84.0.165.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.84.0.165.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\nARM: 9170/1: fix panic when kasan and kprobe are enabled\r\n\r\narm32 uses software to simulate the instruction replaced\nby kprobe. some instructions may be simulated by constructing\nassembly functions. therefore, before executing instruction\nsimulation, it is necessary to construct assembly function\nexecution environment in C language through binding registers.\nafter kasan is enabled, the register binding relationship will\nbe destroyed, resulting in instruction simulation errors and\ncausing kernel panic.\r\n\r\nthe kprobe emulate instruction function is distributed in three\nfiles: actions-common.c actions-arm.c actions-thumb.c, so disable\nKASAN when compiling these files.\r\n\r\nfor example, use kprobe insert on cap_capable+20 after kasan\nenabled, the cap_capable assembly code is as follows:\n\u0026lt;cap_capable\u0026gt;:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne1a05000\tmov\tr5, r0\ne280006c\tadd\tr0, r0, #108    ; 0x6c\ne1a04001\tmov\tr4, r1\ne1a06002\tmov\tr6, r2\ne59fa090\tldr\tsl, [pc, #144]  ;\nebfc7bf8\tbl\tc03aa4b4 \u0026lt;__asan_load4\u0026gt;\ne595706c\tldr\tr7, [r5, #108]  ; 0x6c\ne2859014\tadd\tr9, r5, #20\n......\nThe emulate_ldr assembly code after enabling kasan is as follows:\nc06f1384 \u0026lt;emulate_ldr\u0026gt;:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne282803c\tadd\tr8, r2, #60     ; 0x3c\ne1a05000\tmov\tr5, r0\ne7e37855\tubfx\tr7, r5, #16, #4\ne1a00008\tmov\tr0, r8\ne1a09001\tmov\tr9, r1\ne1a04002\tmov\tr4, r2\nebf35462\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne357000f\tcmp\tr7, #15\ne7e36655\tubfx\tr6, r5, #12, #4\ne205a00f\tand\tsl, r5, #15\n0a000001\tbeq\tc06f13bc \u0026lt;emulate_ldr+0x38\u0026gt;\ne0840107\tadd\tr0, r4, r7, lsl #2\nebf3545c\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne084010a\tadd\tr0, r4, sl, lsl #2\nebf3545a\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne2890010\tadd\tr0, r9, #16\nebf35458\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne5990010\tldr\tr0, [r9, #16]\ne12fff30\tblx\tr0\ne356000f\tcm\tr6, #15\n1a000014\tbne\tc06f1430 \u0026lt;emulate_ldr+0xac\u0026gt;\ne1a06000\tmov\tr6, r0\ne2840040\tadd\tr0, r4, #64     ; 0x40\n......\r\n\r\nwhen running in emulate_ldr to simulate the ldr instruction, panic\noccurred, and the log is as follows:\nUnable to handle kernel NULL pointer dereference at virtual address\n00000090\npgd = ecb46400\n[00000090] *pgd=2e0fa003, *pmd=00000000\nInternal error: Oops: 206 [#1] SMP ARM\nPC is at cap_capable+0x14/0xb0\nLR is at emulate_ldr+0x50/0xc0\npsr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c\nr10: 00000000  r9 : c30897f4  r8 : ecd63cd4\nr7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98\nr3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008\nFlags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user\nControl: 32c5387d  Table: 2d546400  DAC: 55555555\nProcess bash (pid: 1643, stack limit = 0xecd60190)\n(cap_capable) from (kprobe_handler+0x218/0x340)\n(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)\n(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)\n(do_undefinstr) from (__und_svc_finish+0x0/0x30)\n(__und_svc_finish) from (cap_capable+0x18/0xb0)\n(cap_capable) from (cap_vm_enough_memory+0x38/0x48)\n(cap_vm_enough_memory) from\n(security_vm_enough_memory_mm+0x48/0x6c)\n(security_vm_enough_memory_mm) from\n(copy_process.constprop.5+0x16b4/0x25c8)\n(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)\n(_do_fork) from (SyS_clone+0x1c/0x24)\n(SyS_clone) from (__sys_trace_return+0x0/0x10)\nCode: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)(CVE-2021-47618)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix use-after-free after failure to create a snapshot\r\n\r\nAt ioctl.c:create_snapshot(), we allocate a pending snapshot structure and\nthen attach it to the transaction\u0026apos;s list of pending snapshots. After that\nwe call btrfs_commit_transaction(), and if that returns an error we jump\nto \u0026apos;fail\u0026apos; label, where we kfree() the pending snapshot structure. This can\nresult in a later use-after-free of the pending snapshot:\r\n\r\n1) We allocated the pending snapshot and added it to the transaction\u0026apos;s\n   list of pending snapshots;\r\n\r\n2) We call btrfs_commit_transaction(), and it fails either at the first\n   call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().\n   In both cases, we don\u0026apos;t abort the transaction and we release our\n   transaction handle. We jump to the \u0026apos;fail\u0026apos; label and free the pending\n   snapshot structure. We return with the pending snapshot still in the\n   transaction\u0026apos;s list;\r\n\r\n3) Another task commits the transaction. This time there\u0026apos;s no error at\n   all, and then during the transaction commit it accesses a pointer\n   to the pending snapshot structure that the snapshot creation task\n   has already freed, resulting in a user-after-free.\r\n\r\nThis issue could actually be detected by smatch, which produced the\nfollowing warning:\r\n\r\n  fs/btrfs/ioctl.c:843 create_snapshot() warn: \u0026apos;\u0026amp;pending_snapshot-\u0026gt;list\u0026apos; not removed from list\r\n\r\nSo fix this by not having the snapshot creation ioctl directly add the\npending snapshot to the transaction\u0026apos;s list. Instead add the pending\nsnapshot to the transaction handle, and then at btrfs_commit_transaction()\nwe add the snapshot to the list only when we can guarantee that any error\nreturned after that point will result in a transaction abort, in which\ncase the ioctl code can safely free the pending snapshot and no one can\naccess it anymore.(CVE-2022-48733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Avoid field-overflowing memcpy()\r\n\r\nIn preparation for FORTIFY_SOURCE performing compile-time and run-time\nfield bounds checking for memcpy(), memmove(), and memset(), avoid\nintentionally writing across neighboring fields.\r\n\r\nUse flexible arrays instead of zero-element arrays (which look like they\nare always overflowing) and split the cross-field memcpy() into two halves\nthat can be appropriately bounds-checked by the compiler.\r\n\r\nWe were doing:\r\n\r\n\t#define ETH_HLEN  14\n\t#define VLAN_HLEN  4\n\t...\n\t#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)\n\t...\n        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);\n\t...\n        struct mlx5_wqe_eth_seg  *eseg = \u0026amp;wqe-\u0026gt;eth;\n        struct mlx5_wqe_data_seg *dseg = wqe-\u0026gt;data;\n\t...\n\tmemcpy(eseg-\u0026gt;inline_hdr.start, xdptxd-\u0026gt;data, MLX5E_XDP_MIN_INLINE);\r\n\r\ntarget is wqe-\u0026gt;eth.inline_hdr.start (which the compiler sees as being\n2 bytes in size), but copying 18, intending to write across start\n(really vlan_tci, 2 bytes). The remaining 16 bytes get written into\nwqe-\u0026gt;data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr\n(8 bytes).\r\n\r\nstruct mlx5e_tx_wqe {\n        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */\n        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */\n        struct mlx5_wqe_data_seg   data[];               /*    32     0 */\r\n\r\n        /* size: 32, cachelines: 1, members: 3 */\n        /* last cacheline: 32 bytes */\n};\r\n\r\nstruct mlx5_wqe_eth_seg {\n        u8                         swp_outer_l4_offset;  /*     0     1 */\n        u8                         swp_outer_l3_offset;  /*     1     1 */\n        u8                         swp_inner_l4_offset;  /*     2     1 */\n        u8                         swp_inner_l3_offset;  /*     3     1 */\n        u8                         cs_flags;             /*     4     1 */\n        u8                         swp_flags;            /*     5     1 */\n        __be16                     mss;                  /*     6     2 */\n        __be32                     flow_table_metadata;  /*     8     4 */\n        union {\n                struct {\n                        __be16     sz;                   /*    12     2 */\n                        u8         start[2];             /*    14     2 */\n                } inline_hdr;                            /*    12     4 */\n                struct {\n                        __be16     type;                 /*    12     2 */\n                        __be16     vlan_tci;             /*    14     2 */\n                } insert;                                /*    12     4 */\n                __be32             trailer;              /*    12     4 */\n        };                                               /*    12     4 */\r\n\r\n        /* size: 16, cachelines: 1, members: 9 */\n        /* last cacheline: 16 bytes */\n};\r\n\r\nstruct mlx5_wqe_data_seg {\n        __be32                     byte_count;           /*     0     4 */\n        __be32                     lkey;                 /*     4     4 */\n        __be64                     addr;                 /*     8     8 */\r\n\r\n        /* size: 16, cachelines: 1, members: 3 */\n        /* last cacheline: 16 bytes */\n};\r\n\r\nSo, split the memcpy() so the compiler can reason about the buffer\nsizes.\r\n\r\n\u0026quot;pahole\u0026quot; shows no size nor member offset changes to struct mlx5e_tx_wqe\nnor struct mlx5e_umr_wqe. \u0026quot;objdump -d\u0026quot; shows no meaningful object\ncode changes (i.e. only source line number induced differences and\noptimizations).(CVE-2022-48744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: LAPIC: Also cancel preemption timer during SET_LAPIC\r\n\r\nThe below warning is splatting during guest reboot.\r\n\r\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]\n  CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5\n  RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   kvm_vcpu_ioctl+0x279/0x710 [kvm]\n   __x64_sys_ioctl+0x83/0xb0\n   do_syscall_64+0x3b/0xc0\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n  RIP: 0033:0x7fd39797350b\r\n\r\nThis can be triggered by not exposing tsc-deadline mode and doing a reboot in\nthe guest. The lapic_shutdown() function which is called in sys_reboot path\nwill not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears\nAPIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode\nswitch between tsc-deadline and oneshot/periodic, which can result in preemption\ntimer be cancelled in apic_update_lvtt(). However, We can\u0026apos;t depend on this when\nnot exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption\ntimer. Qemu will synchronise states around reset, let\u0026apos;s cancel preemption timer\nunder KVM_SET_LAPIC.(CVE-2022-48765)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: lgdt3306a: Add a check against null-pointer-def\r\n\r\nThe driver should check whether the client provides the platform_data.\r\n\r\nThe following log reveals it:\r\n\r\n[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40\n[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414\n[   29.612820] Call Trace:\n[   29.613030]  \u0026lt;TASK\u0026gt;\n[   29.613201]  dump_stack_lvl+0x56/0x6f\n[   29.613496]  ? kmemdup+0x30/0x40\n[   29.613754]  print_report.cold+0x494/0x6b7\n[   29.614082]  ? kmemdup+0x30/0x40\n[   29.614340]  kasan_report+0x8a/0x190\n[   29.614628]  ? kmemdup+0x30/0x40\n[   29.614888]  kasan_check_range+0x14d/0x1d0\n[   29.615213]  memcpy+0x20/0x60\n[   29.615454]  kmemdup+0x30/0x40\n[   29.615700]  lgdt3306a_probe+0x52/0x310\n[   29.616339]  i2c_device_probe+0x951/0xa90(CVE-2022-48772)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52873)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: dynamic: Synchronize of_changeset_destroy() with the devlink removals\r\n\r\nIn the following sequence:\n  1) of_platform_depopulate()\n  2) of_overlay_remove()\r\n\r\nDuring the step 1, devices are destroyed and devlinks are removed.\nDuring the step 2, OF nodes are destroyed but\n__of_changeset_entry_destroy() can raise warnings related to missing\nof_node_put():\n  ERROR: memory leak, expected refcount 1 instead of 2 ...\r\n\r\nIndeed, during the devlink removals performed at step 1, the removal\nitself releasing the device (and the attached of_node) is done by a job\nqueued in a workqueue and so, it is done asynchronously with respect to\nfunction calls.\nWhen the warning is present, of_node_put() will be called but wrongly\ntoo late from the workqueue job.\r\n\r\nIn order to be sure that any ongoing devlink removals are done before\nthe of_node destruction, synchronize the of_changeset_destroy() with the\ndevlink removals.(CVE-2024-35879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_skbmod: prevent kernel-infoleak\r\n\r\nsyzbot found that tcf_skbmod_dump() was copying four bytes\nfrom kernel stack to user space [1].\r\n\r\nThe issue here is that \u0026apos;struct tc_skbmod\u0026apos; has a four bytes hole.\r\n\r\nWe need to clear the structure before filling fields.\r\n\r\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\n BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n  instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n  copy_to_user_iter lib/iov_iter.c:24 [inline]\n  iterate_ubuf include/linux/iov_iter.h:29 [inline]\n  iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n  iterate_and_advance include/linux/iov_iter.h:271 [inline]\n  _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n  copy_to_iter include/linux/uio.h:196 [inline]\n  simple_copy_to_iter net/core/datagram.c:532 [inline]\n  __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420\n  skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546\n  skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]\n  netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962\n  sock_recvmsg_nosec net/socket.c:1046 [inline]\n  sock_recvmsg+0x2c4/0x340 net/socket.c:1068\n  __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242\n  __do_sys_recvfrom net/socket.c:2260 [inline]\n  __se_sys_recvfrom net/socket.c:2256 [inline]\n  __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was stored to memory at:\n  pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253\n  netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317\n  netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351\n  nlmsg_unicast include/net/netlink.h:1144 [inline]\n  nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610\n  rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741\n  rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]\n  tcf_add_notify net/sched/act_api.c:2048 [inline]\n  tcf_action_add net/sched/act_api.c:2071 [inline]\n  tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119\n  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\n  netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559\n  rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613\n  netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n  netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361\n  netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  ____sys_sendmsg+0x877/0xb60 net/socket.c:2584\n  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n  __sys_sendmsg net/socket.c:2667 [inline]\n  __do_sys_sendmsg net/socket.c:2676 [inline]\n  __se_sys_sendmsg net/socket.c:2674 [inline]\n  __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was stored to memory at:\n  __nla_put lib/nlattr.c:1041 [inline]\n  nla_put+0x1c6/0x230 lib/nlattr.c:1099\n  tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256\n  tcf_action_dump_old net/sched/act_api.c:1191 [inline]\n  tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227\n  tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251\n  tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628\n  tcf_add_notify_msg net/sched/act_api.c:2023 [inline]\n  tcf_add_notify net/sched/act_api.c:2042 [inline]\n  tcf_action_add net/sched/act_api.c:2071 [inline]\n  tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119\n  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\n  netlink_rcv_skb+0x375/0x650 net/netlink/af_netli\n---truncated---(CVE-2024-35893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr\r\n\r\nAlthough ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it\nstill means hlist_for_each_entry_rcu can return an item that got removed\nfrom the list. The memory itself of such item is not freed thanks to RCU\nbut nothing guarantees the actual content of the memory is sane.\r\n\r\nIn particular, the reference count can be zero. This can happen if\nipv6_del_addr is called in parallel. ipv6_del_addr removes the entry\nfrom inet6_addr_lst (hlist_del_init_rcu(\u0026amp;ifp-\u0026gt;addr_lst)) and drops all\nreferences (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough\ntiming, this can happen:\r\n\r\n1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.\r\n\r\n2. Then, the whole ipv6_del_addr is executed for the given entry. The\n   reference count drops to zero and kfree_rcu is scheduled.\r\n\r\n3. ipv6_get_ifaddr continues and tries to increments the reference count\n   (in6_ifa_hold).\r\n\r\n4. The rcu is unlocked and the entry is freed.\r\n\r\n5. The freed entry is returned.\r\n\r\nPrevent increasing of the reference count in such case. The name\nin6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.\r\n\r\n[   41.506330] refcount_t: addition on 0; use-after-free.\n[   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130\n[   41.507413] Modules linked in: veth bridge stp llc\n[   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14\n[   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n[   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130\n[   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 \u0026lt;0f\u0026gt; 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff\n[   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282\n[   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000\n[   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900\n[   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff\n[   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000\n[   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48\n[   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000\n[   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0\n[   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[   41.516799] Call Trace:\n[   41.517037]  \u0026lt;TASK\u0026gt;\n[   41.517249]  ? __warn+0x7b/0x120\n[   41.517535]  ? refcount_warn_saturate+0xa5/0x130\n[   41.517923]  ? report_bug+0x164/0x190\n[   41.518240]  ? handle_bug+0x3d/0x70\n[   41.518541]  ? exc_invalid_op+0x17/0x70\n[   41.520972]  ? asm_exc_invalid_op+0x1a/0x20\n[   41.521325]  ? refcount_warn_saturate+0xa5/0x130\n[   41.521708]  ipv6_get_ifaddr+0xda/0xe0\n[   41.522035]  inet6_rtm_getaddr+0x342/0x3f0\n[   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10\n[   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0\n[   41.523102]  ? netlink_unicast+0x30f/0x390\n[   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[   41.523832]  netlink_rcv_skb+0x53/0x100\n[   41.524157]  netlink_unicast+0x23b/0x390\n[   41.524484]  netlink_sendmsg+0x1f2/0x440\n[   41.524826]  __sys_sendto+0x1d8/0x1f0\n[   41.525145]  __x64_sys_sendto+0x1f/0x30\n[   41.525467]  do_syscall_64+0xa5/0x1b0\n[   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a\n[   41.526213] RIP: 0033:0x7fbc4cfcea9a\n[   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89\n[   41.527942] RSP: 002b:00007f\n---truncated---(CVE-2024-35969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: Fix TASK_SIZE on 64-bit NOMMU\r\n\r\nOn NOMMU, userspace memory can come from anywhere in physical RAM. The\ncurrent definition of TASK_SIZE is wrong if any RAM exists above 4G,\ncausing spurious failures in the userspace access routines.(CVE-2024-35988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: idxd: Fix oops during rmmod on single-CPU platforms\r\n\r\nDuring the removal of the idxd driver, registered offline callback is\ninvoked as part of the clean up process. However, on systems with only\none CPU online, no valid target is available to migrate the\nperf context, resulting in a kernel oops:\r\n\r\n    BUG: unable to handle page fault for address: 000000000002a2b8\n    #PF: supervisor write access in kernel mode\n    #PF: error_code(0x0002) - not-present page\n    PGD 1470e1067 P4D 0\n    Oops: 0002 [#1] PREEMPT SMP NOPTI\n    CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57\n    Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023\n    RIP: 0010:mutex_lock+0x2e/0x50\n    ...\n    Call Trace:\n    \u0026lt;TASK\u0026gt;\n    __die+0x24/0x70\n    page_fault_oops+0x82/0x160\n    do_user_addr_fault+0x65/0x6b0\n    __pfx___rdmsr_safe_on_cpu+0x10/0x10\n    exc_page_fault+0x7d/0x170\n    asm_exc_page_fault+0x26/0x30\n    mutex_lock+0x2e/0x50\n    mutex_lock+0x1e/0x50\n    perf_pmu_migrate_context+0x87/0x1f0\n    perf_event_cpu_offline+0x76/0x90 [idxd]\n    cpuhp_invoke_callback+0xa2/0x4f0\n    __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]\n    cpuhp_thread_fun+0x98/0x150\n    smpboot_thread_fn+0x27/0x260\n    smpboot_thread_fn+0x1af/0x260\n    __pfx_smpboot_thread_fn+0x10/0x10\n    kthread+0x103/0x140\n    __pfx_kthread+0x10/0x10\n    ret_from_fork+0x31/0x50\n    __pfx_kthread+0x10/0x10\n    ret_from_fork_asm+0x1b/0x30\n    \u0026lt;TASK\u0026gt;\r\n\r\nFix the issue by preventing the migration of the perf context to an\ninvalid target.(CVE-2024-35989)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/arm/malidp: fix a possible null pointer dereference\r\n\r\nIn malidp_mw_connector_reset, new memory is allocated with kzalloc, but\nno check is performed. In order to prevent null pointer dereferencing,\nensure that mw_state is checked before calling\n__drm_atomic_helper_connector_reset.(CVE-2024-36014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntls: fix missing memory barrier in tls_init\r\n\r\nIn tls_init(), a write memory barrier is missing, and store-store\nreordering may cause NULL dereference in tls_{setsockopt,getsockopt}.\r\n\r\nCPU0                               CPU1\n-----                              -----\n// In tls_init()\n// In tls_ctx_create()\nctx = kzalloc()\nctx-\u0026gt;sk_proto = READ_ONCE(sk-\u0026gt;sk_prot) -(1)\r\n\r\n// In update_sk_prot()\nWRITE_ONCE(sk-\u0026gt;sk_prot, tls_prots)     -(2)\r\n\r\n                                   // In sock_common_setsockopt()\n                                   READ_ONCE(sk-\u0026gt;sk_prot)-\u0026gt;setsockopt()\r\n\r\n                                   // In tls_{setsockopt,getsockopt}()\n                                   ctx-\u0026gt;sk_proto-\u0026gt;setsockopt()    -(3)\r\n\r\nIn the above scenario, when (1) and (2) are reordered, (3) can observe\nthe NULL value of ctx-\u0026gt;sk_proto, causing NULL dereference.\r\n\r\nTo fix it, we rely on rcu_assign_pointer() which implies the release\nbarrier semantic. By moving rcu_assign_pointer() after ctx-\u0026gt;sk_proto is\ninitialized, we can ensure that ctx-\u0026gt;sk_proto are visible when\nchanging sk-\u0026gt;sk_prot.(CVE-2024-36489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio: delete vq in vp_find_vqs_msix() when request_irq() fails\r\n\r\nWhen request_irq() fails, error path calls vp_del_vqs(). There, as vq is\npresent in the list, free_irq() is called for the same vector. That\ncauses following splat:\r\n\r\n[    0.414355] Trying to free already-free IRQ 27\n[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0\n[    0.414510] Modules linked in:\n[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27\n[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014\n[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0\n[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40\n[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086\n[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000\n[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001\n[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001\n[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760\n[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600\n[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000\n[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0\n[    0.414540] Call Trace:\n[    0.414540]  \u0026lt;TASK\u0026gt;\n[    0.414540]  ? __warn+0x80/0x120\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  ? report_bug+0x164/0x190\n[    0.414540]  ? handle_bug+0x3b/0x70\n[    0.414540]  ? exc_invalid_op+0x17/0x70\n[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  vp_del_vqs+0xc1/0x220\n[    0.414540]  vp_find_vqs_msix+0x305/0x470\n[    0.414540]  vp_find_vqs+0x3e/0x1a0\n[    0.414540]  vp_modern_find_vqs+0x1b/0x70\n[    0.414540]  init_vqs+0x387/0x600\n[    0.414540]  virtnet_probe+0x50a/0xc80\n[    0.414540]  virtio_dev_probe+0x1e0/0x2b0\n[    0.414540]  really_probe+0xc0/0x2c0\n[    0.414540]  ? __pfx___driver_attach+0x10/0x10\n[    0.414540]  __driver_probe_device+0x73/0x120\n[    0.414540]  driver_probe_device+0x1f/0xe0\n[    0.414540]  __driver_attach+0x88/0x180\n[    0.414540]  bus_for_each_dev+0x85/0xd0\n[    0.414540]  bus_add_driver+0xec/0x1f0\n[    0.414540]  driver_register+0x59/0x100\n[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10\n[    0.414540]  virtio_net_driver_init+0x90/0xb0\n[    0.414540]  do_one_initcall+0x58/0x230\n[    0.414540]  kernel_init_freeable+0x1a3/0x2d0\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  kernel_init+0x1a/0x1c0\n[    0.414540]  ret_from_fork+0x31/0x50\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  ret_from_fork_asm+0x1a/0x30\n[    0.414540]  \u0026lt;/TASK\u0026gt;\r\n\r\nFix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix crash on racing fsync and size-extending write into prealloc\r\n\r\nWe have been seeing crashes on duplicate keys in\nbtrfs_set_item_key_safe():\r\n\r\n  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/ctree.c:2620!\n  invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\r\n\r\nWith the following stack trace:\r\n\r\n  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\n  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)\n  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)\n  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\n  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\n  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\n  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\n  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)\n  #8  vfs_fsync_range (fs/sync.c:188:9)\n  #9  vfs_fsync (fs/sync.c:202:9)\n  #10 do_fsync (fs/sync.c:212:9)\n  #11 __do_sys_fdatasync (fs/sync.c:225:9)\n  #12 __se_sys_fdatasync (fs/sync.c:223:1)\n  #13 __x64_sys_fdatasync (fs/sync.c:223:1)\n  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\n  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\n  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\r\n\r\nSo we\u0026apos;re logging a changed extent from fsync, which is splitting an\nextent in the log tree. But this split part already exists in the tree,\ntriggering the BUG().\r\n\r\nThis is the state of the log tree at the time of the crash, dumped with\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\nto get more details than btrfs_print_leaf() gives us:\r\n\r\n  \u0026gt;\u0026gt;\u0026gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0][\u0026quot;eb\u0026quot;])\n  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\n  leaf 33439744 flags 0x100000000000000\n  fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\n                  generation 7 transid 9 size 8192 nbytes 8473563889606862198\n                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n                  sequence 204 flags 0x10(PREALLOC)\n                  atime 1716417703.220000000 (2024-05-22 15:41:43)\n                  ctime 1716417704.983333333 (2024-05-22 15:41:44)\n                  mtime 1716417704.983333333 (2024-05-22 15:41:44)\n                  otime 17592186044416.000000000 (559444-03-08 01:40:16)\n          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\n                  index 195 namelen 3 name: 193\n          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\n                  location key (0 UNKNOWN.0 0) type XATTR\n                  transid 7 data_len 1 name_len 6\n                  name: user.a\n                  data a\n          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\n                  generation 9 type 1 (regular)\n                  extent data disk byte 303144960 nr 12288\n                  extent data offset 0 nr 4096 ram 12288\n                  extent compression 0 (none)\n          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 4096 nr 8192\n          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 8192 nr 4096\n  ...\r\n\r\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\nitem 5 starts at i_size.\r\n\r\nHere is the state of \n---truncated---(CVE-2024-37354)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: nci: Fix uninit-value in nci_rx_work\r\n\r\nsyzbot reported the following uninit-value access issue [1]\r\n\r\nnci_rx_work() parses received packet from ndev-\u0026gt;rx_q. It should be\nvalidated header size, payload size and total packet size before\nprocessing the packet. If an invalid packet is detected, it should be\nsilently discarded.(CVE-2024-38381)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries\r\n\r\nThe allocation failure of mycs-\u0026gt;yuv_scaler_binary in load_video_binaries()\nis followed with a dereference of mycs-\u0026gt;yuv_scaler_binary after the\nfollowing call chain:\r\n\r\nsh_css_pipe_load_binaries()\n  |-\u0026gt; load_video_binaries(mycs-\u0026gt;yuv_scaler_binary == NULL)\n  |\n  |-\u0026gt; sh_css_pipe_unload_binaries()\n        |-\u0026gt; unload_video_binaries()\r\n\r\nIn unload_video_binaries(), it calls to ia_css_binary_unload with argument\n\u0026amp;pipe-\u0026gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the\nsame memory slot as mycs-\u0026gt;yuv_scaler_binary. Thus, a null-pointer\ndereference is triggered.(CVE-2024-38547)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential index out of bounds in color transformation function\r\n\r\nFixes index out of bounds issue in the color transformation function.\nThe issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer\nfunction points (TRANSFER_FUNC_POINTS).\r\n\r\nThe fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the\ntransfer function points. If \u0026apos;i\u0026apos; is out of bounds, an error message is\nlogged and the function returns false to indicate an error.\r\n\r\nReported by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-38552)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fec: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nThere is a deadlock issue found in sungem driver, please refer to the\ncommit ac0a230f719b (\u0026quot;eth: sungem: remove .ndo_poll_controller to avoid\ndeadlocks\u0026quot;). The root cause of the issue is that netpoll is in atomic\ncontext and disable_irq() is called by .ndo_poll_controller interface\nof sungem driver, however, disable_irq() might sleep. After analyzing\nthe implementation of fec_poll_controller(), the fec driver should have\nthe same issue. Due to the fec driver uses NAPI for TX completions, the\n.ndo_poll_controller is unnecessary to be implemented in the fec driver,\nso fec_poll_controller() can be safely removed.(CVE-2024-38553)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issue of net_device\r\n\r\nThere is a reference count leak issue of the object \u0026quot;net_device\u0026quot; in\nax25_dev_device_down(). When the ax25 device is shutting down, the\nax25_dev_device_down() drops the reference count of net_device one\nor zero times depending on if we goto unlock_put or not, which will\ncause memory leak.\r\n\r\nIn order to solve the above issue, decrease the reference count of\nnet_device after dev-\u0026gt;ax25_ptr is set to null.(CVE-2024-38554)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow\r\n\r\nThere is a possibility of buffer overflow in\nshow_rcu_tasks_trace_gp_kthread() if counters, passed\nto sprintf() are huge. Counter numbers, needed for this\nare unrealistically high, but buffer overflow is still\npossible.\r\n\r\nUse snprintf() with buffer size instead of sprintf().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38577)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: bcm - Fix pointer arithmetic\r\n\r\nIn spu2_dump_omd() value of ptr is increased by ciph_key_len\ninstead of hash_iv_len which could lead to going beyond the\nbuffer boundaries.\nFix this bug by changing ciph_key_len to hash_iv_len.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential hang in nilfs_detach_log_writer()\r\n\r\nSyzbot has reported a potential hang in nilfs_detach_log_writer() called\nduring nilfs2 unmount.\r\n\r\nAnalysis revealed that this is because nilfs_segctor_sync(), which\nsynchronizes with the log writer thread, can be called after\nnilfs_segctor_destroy() terminates that thread, as shown in the call trace\nbelow:\r\n\r\nnilfs_detach_log_writer\n  nilfs_segctor_destroy\n    nilfs_segctor_kill_thread  --\u0026gt; Shut down log writer thread\n    flush_work\n      nilfs_iput_work_func\n        nilfs_dispose_list\n          iput\n            nilfs_evict_inode\n              nilfs_transaction_commit\n                nilfs_construct_segment (if inode needs sync)\n                  nilfs_segctor_sync  --\u0026gt; Attempt to synchronize with\n                                          log writer thread\n                           *** DEADLOCK ***\r\n\r\nFix this issue by changing nilfs_segctor_sync() so that the log writer\nthread returns normally without synchronizing after it terminates, and by\nforcing tasks that are already waiting to complete once after the thread\nterminates.\r\n\r\nThe skipped inode metadata flushout will then be processed together in the\nsubsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix use-after-free of timer for log writer thread\r\n\r\nPatch series \u0026quot;nilfs2: fix log writer related issues\u0026quot;.\r\n\r\nThis bug fix series covers three nilfs2 log writer-related issues,\nincluding a timer use-after-free issue and potential deadlock issue on\nunmount, and a potential freeze issue in event synchronization found\nduring their analysis.  Details are described in each commit log.\r\n\r\n\nThis patch (of 3):\r\n\r\nA use-after-free issue has been reported regarding the timer sc_timer on\nthe nilfs_sc_info structure.\r\n\r\nThe problem is that even though it is used to wake up a sleeping log\nwriter thread, sc_timer is not shut down until the nilfs_sc_info structure\nis about to be freed, and is used regardless of the thread\u0026apos;s lifetime.\r\n\r\nFix this issue by limiting the use of sc_timer only while the log writer\nthread is alive.(CVE-2024-38583)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/hns: Modify the print level of CQE error\r\n\r\nToo much print may lead to a panic in kernel. Change ibdev_err() to\nibdev_err_ratelimited(), and change the printing level of cqe dump\nto debug level.(CVE-2024-38590)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\naf_unix: Fix data races in unix_release_sock/unix_stream_sendmsg\r\n\r\nA data-race condition has been identified in af_unix. In one data path,\nthe write function unix_release_sock() atomically writes to\nsk-\u0026gt;sk_shutdown using WRITE_ONCE. However, on the reader side,\nunix_stream_sendmsg() does not read it atomically. Consequently, this\nissue is causing the following KCSAN splat to occur:\r\n\r\n\tBUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg\r\n\r\n\twrite (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:\n\tunix_release_sock (net/unix/af_unix.c:640)\n\tunix_release (net/unix/af_unix.c:1050)\n\tsock_close (net/socket.c:659 net/socket.c:1421)\n\t__fput (fs/file_table.c:422)\n\t__fput_sync (fs/file_table.c:508)\n\t__se_sys_close (fs/open.c:1559 fs/open.c:1541)\n\t__x64_sys_close (fs/open.c:1541)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n\tread to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:\n\tunix_stream_sendmsg (net/unix/af_unix.c:2273)\n\t__sock_sendmsg (net/socket.c:730 net/socket.c:745)\n\t____sys_sendmsg (net/socket.c:2584)\n\t__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)\n\t__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n\tvalue changed: 0x01 -\u0026gt; 0x03\r\n\r\nThe line numbers are related to commit dd5a440a31fa (\u0026quot;Linux 6.9-rc7\u0026quot;).\r\n\r\nCommit e1d09c2c2f57 (\u0026quot;af_unix: Fix data races around sk-\u0026gt;sk_shutdown.\u0026quot;)\naddressed a comparable issue in the past regarding sk-\u0026gt;sk_shutdown.\nHowever, it overlooked resolving this particular data path.\nThis patch only offending unix_stream_sendmsg() function, since the\nother reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issues of ax25_dev\r\n\r\nThe ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference\ncount leak issue of the object \u0026quot;ax25_dev\u0026quot;.\r\n\r\nMemory leak issue in ax25_addr_ax25dev():\r\n\r\nThe reference count of the object \u0026quot;ax25_dev\u0026quot; can be increased multiple\ntimes in ax25_addr_ax25dev(). This will cause a memory leak.\r\n\r\nMemory leak issues in ax25_dev_device_down():\r\n\r\nThe reference count of ax25_dev is set to 1 in ax25_dev_device_up() and\nthen increase the reference count when ax25_dev is added to ax25_dev_list.\nAs a result, the reference count of ax25_dev is 2. But when the device is\nshutting down. The ax25_dev_device_down() drops the reference count once\nor twice depending on if we goto unlock_put or not, which will cause\nmemory leak.\r\n\r\nAs for the issue of ax25_addr_ax25dev(), it is impossible for one pointer\nto be on a list twice. So add a break in ax25_addr_ax25dev(). As for the\nissue of ax25_dev_device_down(), increase the reference count of ax25_dev\nonce in ax25_dev_device_up() and decrease the reference count of ax25_dev\nafter it is removed from the ax25_dev_list.(CVE-2024-38602)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()\r\n\r\npci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()\nfails, the irq vector is not freed, which leads to a memory leak.\r\n\r\nReplace the devm_add_action with devm_add_action_or_reset to ensure\nthe irq vector can be destroyed when it fails.(CVE-2024-38603)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Check \u0026apos;folio\u0026apos; pointer for NULL\r\n\r\nIt can be NULL if bmap is called.(CVE-2024-38625)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Update uart_driver_registered on driver removal\r\n\r\nThe removal of the last MAX3100 device triggers the removal of\nthe driver. However, code doesn\u0026apos;t update the respective global\nvariable and after insmod \u2014 rmmod \u2014 insmod cycle the kernel\noopses:\r\n\r\n  max3100 spi-PRP0001:01: max3100_probe: adding port 0\n  BUG: kernel NULL pointer dereference, address: 0000000000000408\n  ...\n  RIP: 0010:serial_core_register_port+0xa0/0x840\n  ...\n   max3100_probe+0x1b6/0x280 [max3100]\n   spi_probe+0x8d/0xb0\r\n\r\nUpdate the actual state so next time UART driver will be registered\nagain.\r\n\r\nHugo also noticed, that the error path in the probe also affected\nby having the variable set, and not cleared. Instead of clearing it\nmove the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngreybus: lights: check return of get_channel_from_mode\r\n\r\nIf channel for the given node is not found we return null from\nget_channel_from_mode. Make sure we validate the return pointer\nbefore using it in two of the missing places.\r\n\r\nThis was originally reported in [0]:\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\r\n\r\n[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-buf/sw-sync: don\u0026apos;t enable IRQ from sync_print_obj()\r\n\r\nSince commit a6aa8fca4d79 (\u0026quot;dma-buf/sw-sync: Reduce irqsave/irqrestore from\nknown context\u0026quot;) by error replaced spin_unlock_irqrestore() with\nspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite\nsync_print_obj() is called from sync_debugfs_show(), lockdep complains\ninconsistent lock state warning.\r\n\r\nUse plain spin_{lock,unlock}() for sync_print_obj(), for\nsync_debugfs_show() is already using spin_{lock,unlock}_irq().(CVE-2024-38780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/9p: fix uninit-value in p9_client_rpc()\r\n\r\nSyzbot with the help of KMSAN reported the following error:\r\n\r\nBUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]\nBUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n trace_9p_client_res include/trace/events/9p.h:146 [inline]\n p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2175 [inline]\n allocate_slab mm/slub.c:2338 [inline]\n new_slab+0x2de/0x1400 mm/slub.c:2391\n ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525\n __slab_alloc mm/slub.c:3610 [inline]\n __slab_alloc_node mm/slub.c:3663 [inline]\n slab_alloc_node mm/slub.c:3835 [inline]\n kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852\n p9_tag_alloc net/9p/client.c:278 [inline]\n p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641\n p9_client_rpc+0x27e/0x1340 net/9p/client.c:688\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nIf p9_check_errors() fails early in p9_client_rpc(), req-\u0026gt;rc.tag\nwill not be properly initialized. However, trace_9p_client_res()\nends up trying to print it out anyway before p9_client_rpc()\nfinishes.\r\n\r\nFix this issue by assigning default values to p9_fcall fields\nsuch as \u0026apos;tag\u0026apos; and (just in case KMSAN unearths something new) \u0026apos;id\u0026apos;\nduring the tag allocation stage.(CVE-2024-39301)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-39362)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()\r\n\r\nsyzbot reports a kernel bug as below:\r\n\r\nF2FS-fs (loop0): Mounted with checkpoint version = 48b305e4\n==================================================================\nBUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\nBUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]\nBUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\nRead of size 1 at addr ffff88807a58c76c by task syz-executor280/5076\r\n\r\nCPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\n current_nat_addr fs/f2fs/node.h:213 [inline]\n f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\n f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]\n f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925\n ioctl_fiemap fs/ioctl.c:220 [inline]\n do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838\n __do_sys_ioctl fs/ioctl.c:902 [inline]\n __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nThe root cause is we missed to do sanity check on i_xattr_nid during\nf2fs_iget(), so that in fiemap() path, current_nat_addr() will access\nnat_bitmap w/ offset from invalid i_xattr_nid, result in triggering\nkasan bug report, fix it.(CVE-2024-39467)",
  "id": "OESA-2024-1838",
  "modified": "2026-08-06T11:07:18Z",
  "published": "2024-07-12T11:07:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1838"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47618"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48733"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48765"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48772"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52873"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35893"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35989"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36489"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37353"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37354"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38381"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38547"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38552"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38553"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38554"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38577"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38579"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38582"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38583"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38590"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38596"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38602"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38603"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38625"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38633"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38637"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39362"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39467"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47618",
    "CVE-2022-48733",
    "CVE-2022-48744",
    "CVE-2022-48765",
    "CVE-2022-48772",
    "CVE-2023-52873",
    "CVE-2024-35879",
    "CVE-2024-35893",
    "CVE-2024-35969",
    "CVE-2024-35988",
    "CVE-2024-35989",
    "CVE-2024-36014",
    "CVE-2024-36489",
    "CVE-2024-37353",
    "CVE-2024-37354",
    "CVE-2024-38381",
    "CVE-2024-38547",
    "CVE-2024-38552",
    "CVE-2024-38553",
    "CVE-2024-38554",
    "CVE-2024-38577",
    "CVE-2024-38579",
    "CVE-2024-38582",
    "CVE-2024-38583",
    "CVE-2024-38590",
    "CVE-2024-38596",
    "CVE-2024-38602",
    "CVE-2024-38603",
    "CVE-2024-38625",
    "CVE-2024-38633",
    "CVE-2024-38637",
    "CVE-2024-38780",
    "CVE-2024-39301",
    "CVE-2024-39362",
    "CVE-2024-39467"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-218.0.0.121.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-218.0.0.121.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-218.0.0.121.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-218.0.0.121.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: SOF: Fix DSP oops stack dump output contents\r\n\r\nFix @buf arg given to hex_dump_to_buffer() and stack address used\nin dump error output.(CVE-2021-47381)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9170/1: fix panic when kasan and kprobe are enabled\r\n\r\narm32 uses software to simulate the instruction replaced\nby kprobe. some instructions may be simulated by constructing\nassembly functions. therefore, before executing instruction\nsimulation, it is necessary to construct assembly function\nexecution environment in C language through binding registers.\nafter kasan is enabled, the register binding relationship will\nbe destroyed, resulting in instruction simulation errors and\ncausing kernel panic.\r\n\r\nthe kprobe emulate instruction function is distributed in three\nfiles: actions-common.c actions-arm.c actions-thumb.c, so disable\nKASAN when compiling these files.\r\n\r\nfor example, use kprobe insert on cap_capable+20 after kasan\nenabled, the cap_capable assembly code is as follows:\n\u0026lt;cap_capable\u0026gt;:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne1a05000\tmov\tr5, r0\ne280006c\tadd\tr0, r0, #108    ; 0x6c\ne1a04001\tmov\tr4, r1\ne1a06002\tmov\tr6, r2\ne59fa090\tldr\tsl, [pc, #144]  ;\nebfc7bf8\tbl\tc03aa4b4 \u0026lt;__asan_load4\u0026gt;\ne595706c\tldr\tr7, [r5, #108]  ; 0x6c\ne2859014\tadd\tr9, r5, #20\n......\nThe emulate_ldr assembly code after enabling kasan is as follows:\nc06f1384 \u0026lt;emulate_ldr\u0026gt;:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne282803c\tadd\tr8, r2, #60     ; 0x3c\ne1a05000\tmov\tr5, r0\ne7e37855\tubfx\tr7, r5, #16, #4\ne1a00008\tmov\tr0, r8\ne1a09001\tmov\tr9, r1\ne1a04002\tmov\tr4, r2\nebf35462\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne357000f\tcmp\tr7, #15\ne7e36655\tubfx\tr6, r5, #12, #4\ne205a00f\tand\tsl, r5, #15\n0a000001\tbeq\tc06f13bc \u0026lt;emulate_ldr+0x38\u0026gt;\ne0840107\tadd\tr0, r4, r7, lsl #2\nebf3545c\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne084010a\tadd\tr0, r4, sl, lsl #2\nebf3545a\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne2890010\tadd\tr0, r9, #16\nebf35458\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne5990010\tldr\tr0, [r9, #16]\ne12fff30\tblx\tr0\ne356000f\tcm\tr6, #15\n1a000014\tbne\tc06f1430 \u0026lt;emulate_ldr+0xac\u0026gt;\ne1a06000\tmov\tr6, r0\ne2840040\tadd\tr0, r4, #64     ; 0x40\n......\r\n\r\nwhen running in emulate_ldr to simulate the ldr instruction, panic\noccurred, and the log is as follows:\nUnable to handle kernel NULL pointer dereference at virtual address\n00000090\npgd = ecb46400\n[00000090] *pgd=2e0fa003, *pmd=00000000\nInternal error: Oops: 206 [#1] SMP ARM\nPC is at cap_capable+0x14/0xb0\nLR is at emulate_ldr+0x50/0xc0\npsr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c\nr10: 00000000  r9 : c30897f4  r8 : ecd63cd4\nr7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98\nr3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008\nFlags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user\nControl: 32c5387d  Table: 2d546400  DAC: 55555555\nProcess bash (pid: 1643, stack limit = 0xecd60190)\n(cap_capable) from (kprobe_handler+0x218/0x340)\n(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)\n(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)\n(do_undefinstr) from (__und_svc_finish+0x0/0x30)\n(__und_svc_finish) from (cap_capable+0x18/0xb0)\n(cap_capable) from (cap_vm_enough_memory+0x38/0x48)\n(cap_vm_enough_memory) from\n(security_vm_enough_memory_mm+0x48/0x6c)\n(security_vm_enough_memory_mm) from\n(copy_process.constprop.5+0x16b4/0x25c8)\n(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)\n(_do_fork) from (SyS_clone+0x1c/0x24)\n(SyS_clone) from (__sys_trace_return+0x0/0x10)\nCode: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)(CVE-2021-47618)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix use-after-free after failure to create a snapshot\r\n\r\nAt ioctl.c:create_snapshot(), we allocate a pending snapshot structure and\nthen attach it to the transaction\u0026apos;s list of pending snapshots. After that\nwe call btrfs_commit_transaction(), and if that returns an error we jump\nto \u0026apos;fail\u0026apos; label, where we kfree() the pending snapshot structure. This can\nresult in a later use-after-free of the pending snapshot:\r\n\r\n1) We allocated the pending snapshot and added it to the transaction\u0026apos;s\n   list of pending snapshots;\r\n\r\n2) We call btrfs_commit_transaction(), and it fails either at the first\n   call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().\n   In both cases, we don\u0026apos;t abort the transaction and we release our\n   transaction handle. We jump to the \u0026apos;fail\u0026apos; label and free the pending\n   snapshot structure. We return with the pending snapshot still in the\n   transaction\u0026apos;s list;\r\n\r\n3) Another task commits the transaction. This time there\u0026apos;s no error at\n   all, and then during the transaction commit it accesses a pointer\n   to the pending snapshot structure that the snapshot creation task\n   has already freed, resulting in a user-after-free.\r\n\r\nThis issue could actually be detected by smatch, which produced the\nfollowing warning:\r\n\r\n  fs/btrfs/ioctl.c:843 create_snapshot() warn: \u0026apos;\u0026amp;pending_snapshot-\u0026gt;list\u0026apos; not removed from list\r\n\r\nSo fix this by not having the snapshot creation ioctl directly add the\npending snapshot to the transaction\u0026apos;s list. Instead add the pending\nsnapshot to the transaction handle, and then at btrfs_commit_transaction()\nwe add the snapshot to the list only when we can guarantee that any error\nreturned after that point will result in a transaction abort, in which\ncase the ioctl code can safely free the pending snapshot and no one can\naccess it anymore.(CVE-2022-48733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Avoid field-overflowing memcpy()\r\n\r\nIn preparation for FORTIFY_SOURCE performing compile-time and run-time\nfield bounds checking for memcpy(), memmove(), and memset(), avoid\nintentionally writing across neighboring fields.\r\n\r\nUse flexible arrays instead of zero-element arrays (which look like they\nare always overflowing) and split the cross-field memcpy() into two halves\nthat can be appropriately bounds-checked by the compiler.\r\n\r\nWe were doing:\r\n\r\n\t#define ETH_HLEN  14\n\t#define VLAN_HLEN  4\n\t...\n\t#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)\n\t...\n        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);\n\t...\n        struct mlx5_wqe_eth_seg  *eseg = \u0026amp;wqe-\u0026gt;eth;\n        struct mlx5_wqe_data_seg *dseg = wqe-\u0026gt;data;\n\t...\n\tmemcpy(eseg-\u0026gt;inline_hdr.start, xdptxd-\u0026gt;data, MLX5E_XDP_MIN_INLINE);\r\n\r\ntarget is wqe-\u0026gt;eth.inline_hdr.start (which the compiler sees as being\n2 bytes in size), but copying 18, intending to write across start\n(really vlan_tci, 2 bytes). The remaining 16 bytes get written into\nwqe-\u0026gt;data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr\n(8 bytes).\r\n\r\nstruct mlx5e_tx_wqe {\n        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */\n        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */\n        struct mlx5_wqe_data_seg   data[];               /*    32     0 */\r\n\r\n        /* size: 32, cachelines: 1, members: 3 */\n        /* last cacheline: 32 bytes */\n};\r\n\r\nstruct mlx5_wqe_eth_seg {\n        u8                         swp_outer_l4_offset;  /*     0     1 */\n        u8                         swp_outer_l3_offset;  /*     1     1 */\n        u8                         swp_inner_l4_offset;  /*     2     1 */\n        u8                         swp_inner_l3_offset;  /*     3     1 */\n        u8                         cs_flags;             /*     4     1 */\n        u8                         swp_flags;            /*     5     1 */\n        __be16                     mss;                  /*     6     2 */\n        __be32                     flow_table_metadata;  /*     8     4 */\n        union {\n                struct {\n                        __be16     sz;                   /*    12     2 */\n                        u8         start[2];             /*    14     2 */\n                } inline_hdr;                            /*    12     4 */\n                struct {\n                        __be16     type;                 /*    12     2 */\n                        __be16     vlan_tci;             /*    14     2 */\n                } insert;                                /*    12     4 */\n                __be32             trailer;              /*    12     4 */\n        };                                               /*    12     4 */\r\n\r\n        /* size: 16, cachelines: 1, members: 9 */\n        /* last cacheline: 16 bytes */\n};\r\n\r\nstruct mlx5_wqe_data_seg {\n        __be32                     byte_count;           /*     0     4 */\n        __be32                     lkey;                 /*     4     4 */\n        __be64                     addr;                 /*     8     8 */\r\n\r\n        /* size: 16, cachelines: 1, members: 3 */\n        /* last cacheline: 16 bytes */\n};\r\n\r\nSo, split the memcpy() so the compiler can reason about the buffer\nsizes.\r\n\r\n\u0026quot;pahole\u0026quot; shows no size nor member offset changes to struct mlx5e_tx_wqe\nnor struct mlx5e_umr_wqe. \u0026quot;objdump -d\u0026quot; shows no meaningful object\ncode changes (i.e. only source line number induced differences and\noptimizations).(CVE-2022-48744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: LAPIC: Also cancel preemption timer during SET_LAPIC\r\n\r\nThe below warning is splatting during guest reboot.\r\n\r\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]\n  CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5\n  RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   kvm_vcpu_ioctl+0x279/0x710 [kvm]\n   __x64_sys_ioctl+0x83/0xb0\n   do_syscall_64+0x3b/0xc0\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n  RIP: 0033:0x7fd39797350b\r\n\r\nThis can be triggered by not exposing tsc-deadline mode and doing a reboot in\nthe guest. The lapic_shutdown() function which is called in sys_reboot path\nwill not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears\nAPIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode\nswitch between tsc-deadline and oneshot/periodic, which can result in preemption\ntimer be cancelled in apic_update_lvtt(). However, We can\u0026apos;t depend on this when\nnot exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption\ntimer. Qemu will synchronise states around reset, let\u0026apos;s cancel preemption timer\nunder KVM_SET_LAPIC.(CVE-2022-48765)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: lgdt3306a: Add a check against null-pointer-def\r\n\r\nThe driver should check whether the client provides the platform_data.\r\n\r\nThe following log reveals it:\r\n\r\n[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40\n[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414\n[   29.612820] Call Trace:\n[   29.613030]  \u0026lt;TASK\u0026gt;\n[   29.613201]  dump_stack_lvl+0x56/0x6f\n[   29.613496]  ? kmemdup+0x30/0x40\n[   29.613754]  print_report.cold+0x494/0x6b7\n[   29.614082]  ? kmemdup+0x30/0x40\n[   29.614340]  kasan_report+0x8a/0x190\n[   29.614628]  ? kmemdup+0x30/0x40\n[   29.614888]  kasan_check_range+0x14d/0x1d0\n[   29.615213]  memcpy+0x20/0x60\n[   29.615454]  kmemdup+0x30/0x40\n[   29.615700]  lgdt3306a_probe+0x52/0x310\n[   29.616339]  i2c_device_probe+0x951/0xa90(CVE-2022-48772)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: btusb: Add date-\u0026gt;evt_skb is NULL check\r\n\r\nfix crash because of null pointers\r\n\r\n[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8\n[ 6104.969667] #PF: supervisor read access in kernel mode\n[ 6104.969668] #PF: error_code(0x0000) - not-present page\n[ 6104.969670] PGD 0 P4D 0\n[ 6104.969673] Oops: 0000 [#1] SMP NOPTI\n[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]\n[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246\n[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006\n[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000\n[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001\n[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0\n[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90\n[ 6104.969697] FS:  00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000\n[ 6104.969699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0\n[ 6104.969701] PKRU: 55555554\n[ 6104.969702] Call Trace:\n[ 6104.969708]  btusb_mtk_shutdown+0x44/0x80 [btusb]\n[ 6104.969732]  hci_dev_do_close+0x470/0x5c0 [bluetooth]\n[ 6104.969748]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]\n[ 6104.969753]  rfkill_set_block+0x92/0x160\n[ 6104.969755]  rfkill_fop_write+0x136/0x1e0\n[ 6104.969759]  __vfs_write+0x18/0x40\n[ 6104.969761]  vfs_write+0xdf/0x1c0\n[ 6104.969763]  ksys_write+0xb1/0xe0\n[ 6104.969765]  __x64_sys_write+0x1a/0x20\n[ 6104.969769]  do_syscall_64+0x51/0x180\n[ 6104.969771]  entry_SYSCALL_64_after_hwframe+0x44/0xa9\n[ 6104.969773] RIP: 0033:0x7f5a21f18fef\n[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\n[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef\n[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012\n[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017\n[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002\n[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0(CVE-2023-52833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngenirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline\r\n\r\nThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of\ninterrupt affinity reconfiguration via procfs. Instead, the change is\ndeferred until the next instance of the interrupt being triggered on the\noriginal CPU.\r\n\r\nWhen the interrupt next triggers on the original CPU, the new affinity is\nenforced within __irq_move_irq(). A vector is allocated from the new CPU,\nbut the old vector on the original CPU remains and is not immediately\nreclaimed. Instead, apicd-\u0026gt;move_in_progress is flagged, and the reclaiming\nprocess is delayed until the next trigger of the interrupt on the new CPU.\r\n\r\nUpon the subsequent triggering of the interrupt on the new CPU,\nirq_complete_move() adds a task to the old CPU\u0026apos;s vector_cleanup list if it\nremains online. Subsequently, the timer on the old CPU iterates over its\nvector_cleanup list, reclaiming old vectors.\r\n\r\nHowever, a rare scenario arises if the old CPU is outgoing before the\ninterrupt triggers again on the new CPU.\r\n\r\nIn that case irq_force_complete_move() is not invoked on the outgoing CPU\nto reclaim the old apicd-\u0026gt;prev_vector because the interrupt isn\u0026apos;t currently\naffine to the outgoing CPU, and irq_needs_fixup() returns false. Even\nthough __vector_schedule_cleanup() is later called on the new CPU, it\ndoesn\u0026apos;t reclaim apicd-\u0026gt;prev_vector; instead, it simply resets both\napicd-\u0026gt;move_in_progress and apicd-\u0026gt;prev_vector to 0.\r\n\r\nAs a result, the vector remains unreclaimed in vector_matrix, leading to a\nCPU vector leak.\r\n\r\nTo address this issue, move the invocation of irq_force_complete_move()\nbefore the irq_needs_fixup() call to reclaim apicd-\u0026gt;prev_vector, if the\ninterrupt is currently or used to be affine to the outgoing CPU.\r\n\r\nAdditionally, reclaim the vector in __vector_schedule_cleanup() as well,\nfollowing a warning message, although theoretically it should never see\napicd-\u0026gt;move_in_progress with apicd-\u0026gt;prev_cpu pointing to an offline CPU.(CVE-2024-31076)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: dynamic: Synchronize of_changeset_destroy() with the devlink removals\r\n\r\nIn the following sequence:\n  1) of_platform_depopulate()\n  2) of_overlay_remove()\r\n\r\nDuring the step 1, devices are destroyed and devlinks are removed.\nDuring the step 2, OF nodes are destroyed but\n__of_changeset_entry_destroy() can raise warnings related to missing\nof_node_put():\n  ERROR: memory leak, expected refcount 1 instead of 2 ...\r\n\r\nIndeed, during the devlink removals performed at step 1, the removal\nitself releasing the device (and the attached of_node) is done by a job\nqueued in a workqueue and so, it is done asynchronously with respect to\nfunction calls.\nWhen the warning is present, of_node_put() will be called but wrongly\ntoo late from the workqueue job.\r\n\r\nIn order to be sure that any ongoing devlink removals are done before\nthe of_node destruction, synchronize the of_changeset_destroy() with the\ndevlink removals.(CVE-2024-35879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_skbmod: prevent kernel-infoleak\r\n\r\nsyzbot found that tcf_skbmod_dump() was copying four bytes\nfrom kernel stack to user space [1].\r\n\r\nThe issue here is that \u0026apos;struct tc_skbmod\u0026apos; has a four bytes hole.\r\n\r\nWe need to clear the structure before filling fields.\r\n\r\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\n BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n  instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n  copy_to_user_iter lib/iov_iter.c:24 [inline]\n  iterate_ubuf include/linux/iov_iter.h:29 [inline]\n  iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n  iterate_and_advance include/linux/iov_iter.h:271 [inline]\n  _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n  copy_to_iter include/linux/uio.h:196 [inline]\n  simple_copy_to_iter net/core/datagram.c:532 [inline]\n  __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420\n  skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546\n  skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]\n  netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962\n  sock_recvmsg_nosec net/socket.c:1046 [inline]\n  sock_recvmsg+0x2c4/0x340 net/socket.c:1068\n  __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242\n  __do_sys_recvfrom net/socket.c:2260 [inline]\n  __se_sys_recvfrom net/socket.c:2256 [inline]\n  __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was stored to memory at:\n  pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253\n  netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317\n  netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351\n  nlmsg_unicast include/net/netlink.h:1144 [inline]\n  nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610\n  rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741\n  rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]\n  tcf_add_notify net/sched/act_api.c:2048 [inline]\n  tcf_action_add net/sched/act_api.c:2071 [inline]\n  tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119\n  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\n  netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559\n  rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613\n  netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n  netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361\n  netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  ____sys_sendmsg+0x877/0xb60 net/socket.c:2584\n  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n  __sys_sendmsg net/socket.c:2667 [inline]\n  __do_sys_sendmsg net/socket.c:2676 [inline]\n  __se_sys_sendmsg net/socket.c:2674 [inline]\n  __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was stored to memory at:\n  __nla_put lib/nlattr.c:1041 [inline]\n  nla_put+0x1c6/0x230 lib/nlattr.c:1099\n  tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256\n  tcf_action_dump_old net/sched/act_api.c:1191 [inline]\n  tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227\n  tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251\n  tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628\n  tcf_add_notify_msg net/sched/act_api.c:2023 [inline]\n  tcf_add_notify net/sched/act_api.c:2042 [inline]\n  tcf_action_add net/sched/act_api.c:2071 [inline]\n  tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119\n  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\n  netlink_rcv_skb+0x375/0x650 net/netlink/af_netli\n---truncated---(CVE-2024-35893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr\r\n\r\nAlthough ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it\nstill means hlist_for_each_entry_rcu can return an item that got removed\nfrom the list. The memory itself of such item is not freed thanks to RCU\nbut nothing guarantees the actual content of the memory is sane.\r\n\r\nIn particular, the reference count can be zero. This can happen if\nipv6_del_addr is called in parallel. ipv6_del_addr removes the entry\nfrom inet6_addr_lst (hlist_del_init_rcu(\u0026amp;ifp-\u0026gt;addr_lst)) and drops all\nreferences (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough\ntiming, this can happen:\r\n\r\n1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.\r\n\r\n2. Then, the whole ipv6_del_addr is executed for the given entry. The\n   reference count drops to zero and kfree_rcu is scheduled.\r\n\r\n3. ipv6_get_ifaddr continues and tries to increments the reference count\n   (in6_ifa_hold).\r\n\r\n4. The rcu is unlocked and the entry is freed.\r\n\r\n5. The freed entry is returned.\r\n\r\nPrevent increasing of the reference count in such case. The name\nin6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.\r\n\r\n[   41.506330] refcount_t: addition on 0; use-after-free.\n[   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130\n[   41.507413] Modules linked in: veth bridge stp llc\n[   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14\n[   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n[   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130\n[   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 \u0026lt;0f\u0026gt; 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff\n[   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282\n[   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000\n[   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900\n[   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff\n[   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000\n[   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48\n[   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000\n[   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0\n[   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[   41.516799] Call Trace:\n[   41.517037]  \u0026lt;TASK\u0026gt;\n[   41.517249]  ? __warn+0x7b/0x120\n[   41.517535]  ? refcount_warn_saturate+0xa5/0x130\n[   41.517923]  ? report_bug+0x164/0x190\n[   41.518240]  ? handle_bug+0x3d/0x70\n[   41.518541]  ? exc_invalid_op+0x17/0x70\n[   41.520972]  ? asm_exc_invalid_op+0x1a/0x20\n[   41.521325]  ? refcount_warn_saturate+0xa5/0x130\n[   41.521708]  ipv6_get_ifaddr+0xda/0xe0\n[   41.522035]  inet6_rtm_getaddr+0x342/0x3f0\n[   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10\n[   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0\n[   41.523102]  ? netlink_unicast+0x30f/0x390\n[   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[   41.523832]  netlink_rcv_skb+0x53/0x100\n[   41.524157]  netlink_unicast+0x23b/0x390\n[   41.524484]  netlink_sendmsg+0x1f2/0x440\n[   41.524826]  __sys_sendto+0x1d8/0x1f0\n[   41.525145]  __x64_sys_sendto+0x1f/0x30\n[   41.525467]  do_syscall_64+0xa5/0x1b0\n[   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a\n[   41.526213] RIP: 0033:0x7fbc4cfcea9a\n[   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89\n[   41.527942] RSP: 002b:00007f\n---truncated---(CVE-2024-35969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: Fix TASK_SIZE on 64-bit NOMMU\r\n\r\nOn NOMMU, userspace memory can come from anywhere in physical RAM. The\ncurrent definition of TASK_SIZE is wrong if any RAM exists above 4G,\ncausing spurious failures in the userspace access routines.(CVE-2024-35988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/arm/malidp: fix a possible null pointer dereference\r\n\r\nIn malidp_mw_connector_reset, new memory is allocated with kzalloc, but\nno check is performed. In order to prevent null pointer dereferencing,\nensure that mw_state is checked before calling\n__drm_atomic_helper_connector_reset.(CVE-2024-36014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntls: fix missing memory barrier in tls_init\r\n\r\nIn tls_init(), a write memory barrier is missing, and store-store\nreordering may cause NULL dereference in tls_{setsockopt,getsockopt}.\r\n\r\nCPU0                               CPU1\n-----                              -----\n// In tls_init()\n// In tls_ctx_create()\nctx = kzalloc()\nctx-\u0026gt;sk_proto = READ_ONCE(sk-\u0026gt;sk_prot) -(1)\r\n\r\n// In update_sk_prot()\nWRITE_ONCE(sk-\u0026gt;sk_prot, tls_prots)     -(2)\r\n\r\n                                   // In sock_common_setsockopt()\n                                   READ_ONCE(sk-\u0026gt;sk_prot)-\u0026gt;setsockopt()\r\n\r\n                                   // In tls_{setsockopt,getsockopt}()\n                                   ctx-\u0026gt;sk_proto-\u0026gt;setsockopt()    -(3)\r\n\r\nIn the above scenario, when (1) and (2) are reordered, (3) can observe\nthe NULL value of ctx-\u0026gt;sk_proto, causing NULL dereference.\r\n\r\nTo fix it, we rely on rcu_assign_pointer() which implies the release\nbarrier semantic. By moving rcu_assign_pointer() after ctx-\u0026gt;sk_proto is\ninitialized, we can ensure that ctx-\u0026gt;sk_proto are visible when\nchanging sk-\u0026gt;sk_prot.(CVE-2024-36489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio: delete vq in vp_find_vqs_msix() when request_irq() fails\r\n\r\nWhen request_irq() fails, error path calls vp_del_vqs(). There, as vq is\npresent in the list, free_irq() is called for the same vector. That\ncauses following splat:\r\n\r\n[    0.414355] Trying to free already-free IRQ 27\n[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0\n[    0.414510] Modules linked in:\n[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27\n[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014\n[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0\n[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40\n[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086\n[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000\n[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001\n[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001\n[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760\n[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600\n[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000\n[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0\n[    0.414540] Call Trace:\n[    0.414540]  \u0026lt;TASK\u0026gt;\n[    0.414540]  ? __warn+0x80/0x120\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  ? report_bug+0x164/0x190\n[    0.414540]  ? handle_bug+0x3b/0x70\n[    0.414540]  ? exc_invalid_op+0x17/0x70\n[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20\n[    0.414540]  ? free_irq+0x1a1/0x2d0\n[    0.414540]  vp_del_vqs+0xc1/0x220\n[    0.414540]  vp_find_vqs_msix+0x305/0x470\n[    0.414540]  vp_find_vqs+0x3e/0x1a0\n[    0.414540]  vp_modern_find_vqs+0x1b/0x70\n[    0.414540]  init_vqs+0x387/0x600\n[    0.414540]  virtnet_probe+0x50a/0xc80\n[    0.414540]  virtio_dev_probe+0x1e0/0x2b0\n[    0.414540]  really_probe+0xc0/0x2c0\n[    0.414540]  ? __pfx___driver_attach+0x10/0x10\n[    0.414540]  __driver_probe_device+0x73/0x120\n[    0.414540]  driver_probe_device+0x1f/0xe0\n[    0.414540]  __driver_attach+0x88/0x180\n[    0.414540]  bus_for_each_dev+0x85/0xd0\n[    0.414540]  bus_add_driver+0xec/0x1f0\n[    0.414540]  driver_register+0x59/0x100\n[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10\n[    0.414540]  virtio_net_driver_init+0x90/0xb0\n[    0.414540]  do_one_initcall+0x58/0x230\n[    0.414540]  kernel_init_freeable+0x1a3/0x2d0\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  kernel_init+0x1a/0x1c0\n[    0.414540]  ret_from_fork+0x31/0x50\n[    0.414540]  ? __pfx_kernel_init+0x10/0x10\n[    0.414540]  ret_from_fork_asm+0x1a/0x30\n[    0.414540]  \u0026lt;/TASK\u0026gt;\r\n\r\nFix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix crash on racing fsync and size-extending write into prealloc\r\n\r\nWe have been seeing crashes on duplicate keys in\nbtrfs_set_item_key_safe():\r\n\r\n  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/ctree.c:2620!\n  invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\r\n\r\nWith the following stack trace:\r\n\r\n  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\n  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)\n  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)\n  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\n  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\n  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\n  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\n  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)\n  #8  vfs_fsync_range (fs/sync.c:188:9)\n  #9  vfs_fsync (fs/sync.c:202:9)\n  #10 do_fsync (fs/sync.c:212:9)\n  #11 __do_sys_fdatasync (fs/sync.c:225:9)\n  #12 __se_sys_fdatasync (fs/sync.c:223:1)\n  #13 __x64_sys_fdatasync (fs/sync.c:223:1)\n  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\n  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\n  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\r\n\r\nSo we\u0026apos;re logging a changed extent from fsync, which is splitting an\nextent in the log tree. But this split part already exists in the tree,\ntriggering the BUG().\r\n\r\nThis is the state of the log tree at the time of the crash, dumped with\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\nto get more details than btrfs_print_leaf() gives us:\r\n\r\n  \u0026gt;\u0026gt;\u0026gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0][\u0026quot;eb\u0026quot;])\n  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\n  leaf 33439744 flags 0x100000000000000\n  fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\n                  generation 7 transid 9 size 8192 nbytes 8473563889606862198\n                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n                  sequence 204 flags 0x10(PREALLOC)\n                  atime 1716417703.220000000 (2024-05-22 15:41:43)\n                  ctime 1716417704.983333333 (2024-05-22 15:41:44)\n                  mtime 1716417704.983333333 (2024-05-22 15:41:44)\n                  otime 17592186044416.000000000 (559444-03-08 01:40:16)\n          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\n                  index 195 namelen 3 name: 193\n          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\n                  location key (0 UNKNOWN.0 0) type XATTR\n                  transid 7 data_len 1 name_len 6\n                  name: user.a\n                  data a\n          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\n                  generation 9 type 1 (regular)\n                  extent data disk byte 303144960 nr 12288\n                  extent data offset 0 nr 4096 ram 12288\n                  extent compression 0 (none)\n          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 4096 nr 8192\n          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 8192 nr 4096\n  ...\r\n\r\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\nitem 5 starts at i_size.\r\n\r\nHere is the state of \n---truncated---(CVE-2024-37354)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: nci: Fix uninit-value in nci_rx_work\r\n\r\nsyzbot reported the following uninit-value access issue [1]\r\n\r\nnci_rx_work() parses received packet from ndev-\u0026gt;rx_q. It should be\nvalidated header size, payload size and total packet size before\nprocessing the packet. If an invalid packet is detected, it should be\nsilently discarded.(CVE-2024-38381)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries\r\n\r\nThe allocation failure of mycs-\u0026gt;yuv_scaler_binary in load_video_binaries()\nis followed with a dereference of mycs-\u0026gt;yuv_scaler_binary after the\nfollowing call chain:\r\n\r\nsh_css_pipe_load_binaries()\n  |-\u0026gt; load_video_binaries(mycs-\u0026gt;yuv_scaler_binary == NULL)\n  |\n  |-\u0026gt; sh_css_pipe_unload_binaries()\n        |-\u0026gt; unload_video_binaries()\r\n\r\nIn unload_video_binaries(), it calls to ia_css_binary_unload with argument\n\u0026amp;pipe-\u0026gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the\nsame memory slot as mycs-\u0026gt;yuv_scaler_binary. Thus, a null-pointer\ndereference is triggered.(CVE-2024-38547)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential index out of bounds in color transformation function\r\n\r\nFixes index out of bounds issue in the color transformation function.\nThe issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer\nfunction points (TRANSFER_FUNC_POINTS).\r\n\r\nThe fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the\ntransfer function points. If \u0026apos;i\u0026apos; is out of bounds, an error message is\nlogged and the function returns false to indicate an error.\r\n\r\nReported by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-38552)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issue of net_device\r\n\r\nThere is a reference count leak issue of the object \u0026quot;net_device\u0026quot; in\nax25_dev_device_down(). When the ax25 device is shutting down, the\nax25_dev_device_down() drops the reference count of net_device one\nor zero times depending on if we goto unlock_put or not, which will\ncause memory leak.\r\n\r\nIn order to solve the above issue, decrease the reference count of\nnet_device after dev-\u0026gt;ax25_ptr is set to null.(CVE-2024-38554)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow\r\n\r\nThere is a possibility of buffer overflow in\nshow_rcu_tasks_trace_gp_kthread() if counters, passed\nto sprintf() are huge. Counter numbers, needed for this\nare unrealistically high, but buffer overflow is still\npossible.\r\n\r\nUse snprintf() with buffer size instead of sprintf().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38577)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: bcm - Fix pointer arithmetic\r\n\r\nIn spu2_dump_omd() value of ptr is increased by ciph_key_len\ninstead of hash_iv_len which could lead to going beyond the\nbuffer boundaries.\nFix this bug by changing ciph_key_len to hash_iv_len.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential hang in nilfs_detach_log_writer()\r\n\r\nSyzbot has reported a potential hang in nilfs_detach_log_writer() called\nduring nilfs2 unmount.\r\n\r\nAnalysis revealed that this is because nilfs_segctor_sync(), which\nsynchronizes with the log writer thread, can be called after\nnilfs_segctor_destroy() terminates that thread, as shown in the call trace\nbelow:\r\n\r\nnilfs_detach_log_writer\n  nilfs_segctor_destroy\n    nilfs_segctor_kill_thread  --\u0026gt; Shut down log writer thread\n    flush_work\n      nilfs_iput_work_func\n        nilfs_dispose_list\n          iput\n            nilfs_evict_inode\n              nilfs_transaction_commit\n                nilfs_construct_segment (if inode needs sync)\n                  nilfs_segctor_sync  --\u0026gt; Attempt to synchronize with\n                                          log writer thread\n                           *** DEADLOCK ***\r\n\r\nFix this issue by changing nilfs_segctor_sync() so that the log writer\nthread returns normally without synchronizing after it terminates, and by\nforcing tasks that are already waiting to complete once after the thread\nterminates.\r\n\r\nThe skipped inode metadata flushout will then be processed together in the\nsubsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix use-after-free of timer for log writer thread\r\n\r\nPatch series \u0026quot;nilfs2: fix log writer related issues\u0026quot;.\r\n\r\nThis bug fix series covers three nilfs2 log writer-related issues,\nincluding a timer use-after-free issue and potential deadlock issue on\nunmount, and a potential freeze issue in event synchronization found\nduring their analysis.  Details are described in each commit log.\r\n\r\n\nThis patch (of 3):\r\n\r\nA use-after-free issue has been reported regarding the timer sc_timer on\nthe nilfs_sc_info structure.\r\n\r\nThe problem is that even though it is used to wake up a sleeping log\nwriter thread, sc_timer is not shut down until the nilfs_sc_info structure\nis about to be freed, and is used regardless of the thread\u0026apos;s lifetime.\r\n\r\nFix this issue by limiting the use of sc_timer only while the log writer\nthread is alive.(CVE-2024-38583)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/hns: Modify the print level of CQE error\r\n\r\nToo much print may lead to a panic in kernel. Change ibdev_err() to\nibdev_err_ratelimited(), and change the printing level of cqe dump\nto debug level.(CVE-2024-38590)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix resync softlockup when bitmap size is less than array size\r\n\r\nIs is reported that for dm-raid10, lvextend + lvchange --syncaction will\ntrigger following softlockup:\r\n\r\nkernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]\nCPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1\nRIP: 0010:_raw_spin_unlock_irq+0x13/0x30\nCall Trace:\n \u0026lt;TASK\u0026gt;\n md_bitmap_start_sync+0x6b/0xf0\n raid10_sync_request+0x25c/0x1b40 [raid10]\n md_do_sync+0x64b/0x1020\n md_thread+0xa7/0x170\n kthread+0xcf/0x100\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1a/0x30\r\n\r\nAnd the detailed process is as follows:\r\n\r\nmd_do_sync\n j = mddev-\u0026gt;resync_min\n while (j \u0026lt; max_sectors)\n  sectors = raid10_sync_request(mddev, j, \u0026amp;skipped)\n   if (!md_bitmap_start_sync(..., \u0026amp;sync_blocks))\n    // md_bitmap_start_sync set sync_blocks to 0\n    return sync_blocks + sectors_skippe;\n  // sectors = 0;\n  j += sectors;\n  // j never change\r\n\r\nRoot cause is that commit 301867b1c168 (\u0026quot;md/raid10: check\nslab-out-of-bounds in md_bitmap_get_counter\u0026quot;) return early from\nmd_bitmap_get_counter(), without setting returned blocks.\r\n\r\nFix this problem by always set returned blocks from\nmd_bitmap_get_counter\u0026quot;(), as it used to be.\r\n\r\nNoted that this patch just fix the softlockup problem in kernel, the\ncase that bitmap size doesn\u0026apos;t match array size still need to be fixed.(CVE-2024-38598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issues of ax25_dev\r\n\r\nThe ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference\ncount leak issue of the object \u0026quot;ax25_dev\u0026quot;.\r\n\r\nMemory leak issue in ax25_addr_ax25dev():\r\n\r\nThe reference count of the object \u0026quot;ax25_dev\u0026quot; can be increased multiple\ntimes in ax25_addr_ax25dev(). This will cause a memory leak.\r\n\r\nMemory leak issues in ax25_dev_device_down():\r\n\r\nThe reference count of ax25_dev is set to 1 in ax25_dev_device_up() and\nthen increase the reference count when ax25_dev is added to ax25_dev_list.\nAs a result, the reference count of ax25_dev is 2. But when the device is\nshutting down. The ax25_dev_device_down() drops the reference count once\nor twice depending on if we goto unlock_put or not, which will cause\nmemory leak.\r\n\r\nAs for the issue of ax25_addr_ax25dev(), it is impossible for one pointer\nto be on a list twice. So add a break in ax25_addr_ax25dev(). As for the\nissue of ax25_dev_device_down(), increase the reference count of ax25_dev\nonce in ax25_dev_device_up() and decrease the reference count of ax25_dev\nafter it is removed from the ax25_dev_list.(CVE-2024-38602)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()\r\n\r\npci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()\nfails, the irq vector is not freed, which leads to a memory leak.\r\n\r\nReplace the devm_add_action with devm_add_action_or_reset to ensure\nthe irq vector can be destroyed when it fails.(CVE-2024-38603)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpufreq: exit() callback is optional\r\n\r\nThe exit() callback is optional and shouldn\u0026apos;t be called without checking\na valid pointer first.\r\n\r\nAlso, we must clear freq_table pointer even if the exit() callback isn\u0026apos;t\npresent.(CVE-2024-38615)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: stk1160: fix bounds checking in stk1160_copy_video()\r\n\r\nThe subtract in this condition is reversed.  The -\u0026gt;length is the length\nof the buffer.  The -\u0026gt;bytesused is how many bytes we have copied thus\nfar.  When the condition is reversed that means the result of the\nsubtraction is always negative but since it\u0026apos;s unsigned then the result\nis a very high positive value.  That means the overflow check is never\ntrue.\r\n\r\nAdditionally, the -\u0026gt;bytesused doesn\u0026apos;t actually work for this purpose\nbecause we\u0026apos;re not writing to \u0026quot;buf-\u0026gt;mem + buf-\u0026gt;bytesused\u0026quot;.  Instead, the\nmath to calculate the destination where we are writing is a bit\ninvolved.  You calculate the number of full lines already written,\nmultiply by two, skip a line if necessary so that we start on an odd\nnumbered line, and add the offset into the line.\r\n\r\nTo fix this buffer overflow, just take the actual destination where we\nare writing, if the offset is already out of bounds print an error and\nreturn.  Otherwise, write up to buf-\u0026gt;length bytes.(CVE-2024-38621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Use variable length array instead of fixed size\r\n\r\nShould fix smatch warning:\n\tntfs_set_label() error: __builtin_memcpy() \u0026apos;uni-\u0026gt;name\u0026apos; too small (20 vs 256)(CVE-2024-38623)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Check \u0026apos;folio\u0026apos; pointer for NULL\r\n\r\nIt can be NULL if bmap is called.(CVE-2024-38625)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Update uart_driver_registered on driver removal\r\n\r\nThe removal of the last MAX3100 device triggers the removal of\nthe driver. However, code doesn\u0026apos;t update the respective global\nvariable and after insmod \u2014 rmmod \u2014 insmod cycle the kernel\noopses:\r\n\r\n  max3100 spi-PRP0001:01: max3100_probe: adding port 0\n  BUG: kernel NULL pointer dereference, address: 0000000000000408\n  ...\n  RIP: 0010:serial_core_register_port+0xa0/0x840\n  ...\n   max3100_probe+0x1b6/0x280 [max3100]\n   spi_probe+0x8d/0xb0\r\n\r\nUpdate the actual state so next time UART driver will be registered\nagain.\r\n\r\nHugo also noticed, that the error path in the probe also affected\nby having the variable set, and not cleared. Instead of clearing it\nmove the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Lock port-\u0026gt;lock when calling uart_handle_cts_change()\r\n\r\nuart_handle_cts_change() has to be called with port lock taken,\nSince we run it in a separate work, the lock may not be taken at\nthe time of running. Make sure that it\u0026apos;s taken by explicitly doing\nthat. Without it we got a splat:\r\n\r\n  WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0\n  ...\n  Workqueue: max3100-0 max3100_work [max3100]\n  RIP: 0010:uart_handle_cts_change+0xa6/0xb0\n  ...\n   max3100_handlerx+0xc5/0x110 [max3100]\n   max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngreybus: lights: check return of get_channel_from_mode\r\n\r\nIf channel for the given node is not found we return null from\nget_channel_from_mode. Make sure we validate the return pointer\nbefore using it in two of the missing places.\r\n\r\nThis was originally reported in [0]:\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\r\n\r\n[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-buf/sw-sync: don\u0026apos;t enable IRQ from sync_print_obj()\r\n\r\nSince commit a6aa8fca4d79 (\u0026quot;dma-buf/sw-sync: Reduce irqsave/irqrestore from\nknown context\u0026quot;) by error replaced spin_unlock_irqrestore() with\nspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite\nsync_print_obj() is called from sync_debugfs_show(), lockdep complains\ninconsistent lock state warning.\r\n\r\nUse plain spin_{lock,unlock}() for sync_print_obj(), for\nsync_debugfs_show() is already using spin_{lock,unlock}_irq().(CVE-2024-38780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/9p: fix uninit-value in p9_client_rpc()\r\n\r\nSyzbot with the help of KMSAN reported the following error:\r\n\r\nBUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]\nBUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n trace_9p_client_res include/trace/events/9p.h:146 [inline]\n p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2175 [inline]\n allocate_slab mm/slub.c:2338 [inline]\n new_slab+0x2de/0x1400 mm/slub.c:2391\n ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525\n __slab_alloc mm/slub.c:3610 [inline]\n __slab_alloc_node mm/slub.c:3663 [inline]\n slab_alloc_node mm/slub.c:3835 [inline]\n kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852\n p9_tag_alloc net/9p/client.c:278 [inline]\n p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641\n p9_client_rpc+0x27e/0x1340 net/9p/client.c:688\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nIf p9_check_errors() fails early in p9_client_rpc(), req-\u0026gt;rc.tag\nwill not be properly initialized. However, trace_9p_client_res()\nends up trying to print it out anyway before p9_client_rpc()\nfinishes.\r\n\r\nFix this issue by assigning default values to p9_fcall fields\nsuch as \u0026apos;tag\u0026apos; and (just in case KMSAN unearths something new) \u0026apos;id\u0026apos;\nduring the tag allocation stage.(CVE-2024-39301)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-39362)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()\r\n\r\nsyzbot reports a kernel bug as below:\r\n\r\nF2FS-fs (loop0): Mounted with checkpoint version = 48b305e4\n==================================================================\nBUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\nBUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]\nBUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\nRead of size 1 at addr ffff88807a58c76c by task syz-executor280/5076\r\n\r\nCPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\n current_nat_addr fs/f2fs/node.h:213 [inline]\n f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\n f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]\n f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925\n ioctl_fiemap fs/ioctl.c:220 [inline]\n do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838\n __do_sys_ioctl fs/ioctl.c:902 [inline]\n __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nThe root cause is we missed to do sanity check on i_xattr_nid during\nf2fs_iget(), so that in fiemap() path, current_nat_addr() will access\nnat_bitmap w/ offset from invalid i_xattr_nid, result in triggering\nkasan bug report, fix it.(CVE-2024-39467)",
  "id": "OESA-2024-1839",
  "modified": "2026-08-06T11:07:18Z",
  "published": "2024-07-12T11:07:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1839"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47381"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47618"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48733"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48765"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48772"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31076"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35893"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36489"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37353"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37354"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38381"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38547"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38552"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38554"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38577"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38579"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38582"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38583"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38590"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38598"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38602"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38603"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38615"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38623"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38625"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38633"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38634"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38637"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39362"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39467"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47381",
    "CVE-2021-47618",
    "CVE-2022-48733",
    "CVE-2022-48744",
    "CVE-2022-48765",
    "CVE-2022-48772",
    "CVE-2023-52833",
    "CVE-2024-31076",
    "CVE-2024-35879",
    "CVE-2024-35893",
    "CVE-2024-35969",
    "CVE-2024-35988",
    "CVE-2024-36014",
    "CVE-2024-36489",
    "CVE-2024-37353",
    "CVE-2024-37354",
    "CVE-2024-38381",
    "CVE-2024-38547",
    "CVE-2024-38552",
    "CVE-2024-38554",
    "CVE-2024-38577",
    "CVE-2024-38579",
    "CVE-2024-38582",
    "CVE-2024-38583",
    "CVE-2024-38590",
    "CVE-2024-38598",
    "CVE-2024-38602",
    "CVE-2024-38603",
    "CVE-2024-38615",
    "CVE-2024-38621",
    "CVE-2024-38623",
    "CVE-2024-38625",
    "CVE-2024-38633",
    "CVE-2024-38634",
    "CVE-2024-38637",
    "CVE-2024-38780",
    "CVE-2024-39301",
    "CVE-2024-39362",
    "CVE-2024-39467"
  ]
}