CVE-2023-4134 (GCVE-0-2023-4134)

Vulnerability from cvelistv5 – Published: 2024-11-14 10:44 – Updated: 2024-11-14 19:34

Title

Kernel: cyttsp4_core: use-after-free in cyttsp4_watchdog_work()

Summary

A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service.

Severity

5.5 (Medium)


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

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2024-11-14 18:53 UTC

CWE

CWE-416 - Use After Free

Assigner

fedora CNA under the redhat root

CNA scorecard C 69/100 over 38 records in the last 180 days details

References

2 references

URL	Tags
https://access.redhat.com/security/cve/CVE-2023-4134	vdb-entryx_refsource_REDHAT
https://bugzilla.redhat.com/show_bug.cgi?id=2221700	issue-trackingx_refsource_REDHAT

Impacted products

5 products

Vendor	Product	Version
		Unaffected: dbe836576f12743a7d2d170ad4ad4fd324c4d47a , < * (git)
Red Hat	Red Hat Enterprise Linux 6	cpe:/o:redhat:enterprise_linux:6
Red Hat	Red Hat Enterprise Linux 7	cpe:/o:redhat:enterprise_linux:7
Red Hat	Red Hat Enterprise Linux 8	cpe:/o:redhat:enterprise_linux:8
Red Hat	Red Hat Enterprise Linux 9	cpe:/o:redhat:enterprise_linux:9

Date Public

2023-04-21 00:00

Credits

Red Hat would like to thank Duoming Zhou for reporting this issue.

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-4134",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-11-14T18:53:48.023616Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-11-14T19:34:19.393Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://github.com/torvalds/linux",
          "packageName": "kernel",
          "repo": "https://github.com/torvalds/linux",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "dbe836576f12743a7d2d170ad4ad4fd324c4d47a",
              "versionType": "git"
            }
          ]
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:6"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel",
          "product": "Red Hat Enterprise Linux 6",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:7"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel",
          "product": "Red Hat Enterprise Linux 7",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:7"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel-rt",
          "product": "Red Hat Enterprise Linux 7",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:8"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel",
          "product": "Red Hat Enterprise Linux 8",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:8"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel-rt",
          "product": "Red Hat Enterprise Linux 8",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:9"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel",
          "product": "Red Hat Enterprise Linux 9",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:9"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel-rt",
          "product": "Red Hat Enterprise Linux 9",
          "vendor": "Red Hat"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "value": "Red Hat would like to thank Duoming Zhou for reporting this issue."
        }
      ],
      "datePublic": "2023-04-21T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "namespace": "https://access.redhat.com/security/updates/classification/",
              "value": "Moderate"
            },
            "type": "Red Hat severity rating"
          }
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "HIGH",
            "baseScore": 5.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-416",
              "description": "Use After Free",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-11-14T10:44:42.864Z",
        "orgId": "92fb86c3-55a5-4fb5-9c3f-4757b9e96dc5",
        "shortName": "fedora"
      },
      "references": [
        {
          "tags": [
            "vdb-entry",
            "x_refsource_REDHAT"
          ],
          "url": "https://access.redhat.com/security/cve/CVE-2023-4134"
        },
        {
          "name": "RHBZ#2221700",
          "tags": [
            "issue-tracking",
            "x_refsource_REDHAT"
          ],
          "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2221700"
        }
      ],
      "timeline": [
        {
          "lang": "en",
          "time": "2023-07-10T00:00:00.000Z",
          "value": "Reported to Red Hat."
        },
        {
          "lang": "en",
          "time": "2023-04-21T00:00:00.000Z",
          "value": "Made public."
        }
      ],
      "title": "Kernel: cyttsp4_core: use-after-free in cyttsp4_watchdog_work()",
      "x_redhatCweChain": "CWE-416: Use After Free"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "92fb86c3-55a5-4fb5-9c3f-4757b9e96dc5",
    "assignerShortName": "fedora",
    "cveId": "CVE-2023-4134",
    "datePublished": "2024-11-14T10:44:42.864Z",
    "dateReserved": "2023-08-03T09:50:51.782Z",
    "dateUpdated": "2024-11-14T19:34:19.393Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2023-4134",
      "date": "2026-10-22",
      "epss": "0.002",
      "percentile": "0.09291"
    },
    "microsoft_vex": {
      "current_release_date": "2026-03-31T14:37:04.000Z",
      "cve": "CVE-2023-4134",
      "id": "msrc_CVE-2023-4134",
      "initial_release_date": "2024-11-02T00:00:00.000Z",
      "product_status:under_investigation": "3",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "Kernel: cyttsp4_core: use-after-free in cyttsp4_watchdog_work()",
      "url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2023-4134.json",
      "version": "3"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "collectionURL": "https://github.com/torvalds/linux",
                "packageName": "kernel",
                "repo": "https://github.com/torvalds/linux",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "unaffected",
                    "version": "dbe836576f12743a7d2d170ad4ad4fd324c4d47a",
                    "versionType": "git"
                  }
                ]
              },
              {
                "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
                "cpes": [
                  "cpe:/o:redhat:enterprise_linux:6"
                ],
                "defaultStatus": "unaffected",
                "packageName": "kernel",
                "product": "Red Hat Enterprise Linux 6",
                "vendor": "Red Hat"
              },
              {
                "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
                "cpes": [
                  "cpe:/o:redhat:enterprise_linux:7"
                ],
                "defaultStatus": "unaffected",
                "packageName": "kernel",
                "product": "Red Hat Enterprise Linux 7",
                "vendor": "Red Hat"
              },
              {
                "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
                "cpes": [
                  "cpe:/o:redhat:enterprise_linux:7"
                ],
                "defaultStatus": "unaffected",
                "packageName": "kernel-rt",
                "product": "Red Hat Enterprise Linux 7",
                "vendor": "Red Hat"
              },
              {
                "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
                "cpes": [
                  "cpe:/o:redhat:enterprise_linux:8"
                ],
                "defaultStatus": "unaffected",
                "packageName": "kernel",
                "product": "Red Hat Enterprise Linux 8",
                "vendor": "Red Hat"
              },
              {
                "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
                "cpes": [
                  "cpe:/o:redhat:enterprise_linux:8"
                ],
                "defaultStatus": "unaffected",
                "packageName": "kernel-rt",
                "product": "Red Hat Enterprise Linux 8",
                "vendor": "Red Hat"
              },
              {
                "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
                "cpes": [
                  "cpe:/o:redhat:enterprise_linux:9"
                ],
                "defaultStatus": "unaffected",
                "packageName": "kernel",
                "product": "Red Hat Enterprise Linux 9",
                "vendor": "Red Hat"
              },
              {
                "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
                "cpes": [
                  "cpe:/o:redhat:enterprise_linux:9"
                ],
                "defaultStatus": "unaffected",
                "packageName": "kernel-rt",
                "product": "Red Hat Enterprise Linux 9",
                "vendor": "Red Hat"
              }
            ],
            "source": "patrick@puiterwijk.org"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "98C491C7-598A-4D36-BA4F-3505A5727ED1",
                    "versionEndExcluding": "6.5",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          },
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:fedoraproject:fedora:38:*:*:*:*:*:*:*",
                    "matchCriteriaId": "CC559B26-5DFC-4B7A-A27C-B77DE755DFF9",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service."
          },
          {
            "lang": "es",
            "value": "Se encontr\u00f3 una vulnerabilidad de use-after-free en el controlador cyttsp4_core del kernel de Linux. Este problema se produce en la rutina de limpieza del dispositivo debido a un posible rearme del watchdog_timer desde la cola de trabajo. Esto podr\u00eda permitir que un usuario local bloquee el sistema, lo que provocar\u00eda una denegaci\u00f3n de servicio. "
          }
        ],
        "id": "CVE-2023-4134",
        "lastModified": "2026-06-17T06:37:09.330",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 5.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 3.6,
              "source": "patrick@puiterwijk.org",
              "type": "Secondary"
            },
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 5.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 3.6,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2023-4134",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-11-14T18:53:48.023616Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-11-14T11:15:03.730",
        "references": [
          {
            "source": "patrick@puiterwijk.org",
            "tags": [
              "Third Party Advisory"
            ],
            "url": "https://access.redhat.com/security/cve/CVE-2023-4134"
          },
          {
            "source": "patrick@puiterwijk.org",
            "tags": [
              "Issue Tracking",
              "Patch",
              "Third Party Advisory"
            ],
            "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2221700"
          }
        ],
        "sourceIdentifier": "patrick@puiterwijk.org",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-416"
              }
            ],
            "source": "patrick@puiterwijk.org",
            "type": "Secondary"
          },
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-416"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2025-11-21T14:23:15+00:00",
      "cve": "CVE-2023-4134",
      "id": "CVE-2023-4134",
      "initial_release_date": "2023-04-21T00:00:00+00:00",
      "product_status:known_not_affected": "198",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: cyttsp4_core: use-after-free in cyttsp4_watchdog_work()",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-4134.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2023-4134",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-11-14T18:53:48.023616Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-11-14T18:54:29.886Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "collectionURL": "https://github.com/torvalds/linux",
              "packageName": "kernel",
              "repo": "https://github.com/torvalds/linux",
              "versions": [
                {
                  "lessThan": "*",
                  "status": "unaffected",
                  "version": "dbe836576f12743a7d2d170ad4ad4fd324c4d47a",
                  "versionType": "git"
                }
              ]
            },
            {
              "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
              "cpes": [
                "cpe:/o:redhat:enterprise_linux:6"
              ],
              "defaultStatus": "unaffected",
              "packageName": "kernel",
              "product": "Red Hat Enterprise Linux 6",
              "vendor": "Red Hat"
            },
            {
              "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
              "cpes": [
                "cpe:/o:redhat:enterprise_linux:7"
              ],
              "defaultStatus": "unaffected",
              "packageName": "kernel",
              "product": "Red Hat Enterprise Linux 7",
              "vendor": "Red Hat"
            },
            {
              "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
              "cpes": [
                "cpe:/o:redhat:enterprise_linux:7"
              ],
              "defaultStatus": "unaffected",
              "packageName": "kernel-rt",
              "product": "Red Hat Enterprise Linux 7",
              "vendor": "Red Hat"
            },
            {
              "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
              "cpes": [
                "cpe:/o:redhat:enterprise_linux:8"
              ],
              "defaultStatus": "unaffected",
              "packageName": "kernel",
              "product": "Red Hat Enterprise Linux 8",
              "vendor": "Red Hat"
            },
            {
              "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
              "cpes": [
                "cpe:/o:redhat:enterprise_linux:8"
              ],
              "defaultStatus": "unaffected",
              "packageName": "kernel-rt",
              "product": "Red Hat Enterprise Linux 8",
              "vendor": "Red Hat"
            },
            {
              "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
              "cpes": [
                "cpe:/o:redhat:enterprise_linux:9"
              ],
              "defaultStatus": "unaffected",
              "packageName": "kernel",
              "product": "Red Hat Enterprise Linux 9",
              "vendor": "Red Hat"
            },
            {
              "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
              "cpes": [
                "cpe:/o:redhat:enterprise_linux:9"
              ],
              "defaultStatus": "unaffected",
              "packageName": "kernel-rt",
              "product": "Red Hat Enterprise Linux 9",
              "vendor": "Red Hat"
            }
          ],
          "credits": [
            {
              "lang": "en",
              "value": "Red Hat would like to thank Duoming Zhou for reporting this issue."
            }
          ],
          "datePublic": "2023-04-21T00:00:00.000Z",
          "descriptions": [
            {
              "lang": "en",
              "value": "A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service."
            }
          ],
          "metrics": [
            {
              "other": {
                "content": {
                  "namespace": "https://access.redhat.com/security/updates/classification/",
                  "value": "Moderate"
                },
                "type": "Red Hat severity rating"
              }
            },
            {
              "cvssV3_1": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 5.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "format": "CVSS"
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-416",
                  "description": "Use After Free",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2024-11-14T10:44:42.864Z",
            "orgId": "92fb86c3-55a5-4fb5-9c3f-4757b9e96dc5",
            "shortName": "fedora"
          },
          "references": [
            {
              "tags": [
                "vdb-entry",
                "x_refsource_REDHAT"
              ],
              "url": "https://access.redhat.com/security/cve/CVE-2023-4134"
            },
            {
              "name": "RHBZ#2221700",
              "tags": [
                "issue-tracking",
                "x_refsource_REDHAT"
              ],
              "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2221700"
            }
          ],
          "timeline": [
            {
              "lang": "en",
              "time": "2023-07-10T00:00:00.000Z",
              "value": "Reported to Red Hat."
            },
            {
              "lang": "en",
              "time": "2023-04-21T00:00:00.000Z",
              "value": "Made public."
            }
          ],
          "title": "Kernel: cyttsp4_core: use-after-free in cyttsp4_watchdog_work()",
          "x_redhatCweChain": "CWE-416: Use After Free"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "92fb86c3-55a5-4fb5-9c3f-4757b9e96dc5",
        "assignerShortName": "fedora",
        "cveId": "CVE-2023-4134",
        "datePublished": "2024-11-14T10:44:42.864Z",
        "dateReserved": "2023-08-03T09:50:51.782Z",
        "dateUpdated": "2024-11-14T19:34:19.393Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}

CERTFR-2024-AVI-0263

Vulnerability from certfr_avis - Published: 2024-03-29 - Updated: 2024-03-29

De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une exécution de code arbitraire à distance.

Solution

Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).

None

Impacted products

Vendor	Product	Description
Ubuntu	Ubuntu	Ubuntu 16.04 ESM
Ubuntu	Ubuntu	Ubuntu 18.04 ESM
Ubuntu	Ubuntu	Ubuntu 20.04 LTS
Ubuntu	Ubuntu	Ubuntu 23.10
Ubuntu	Ubuntu	Ubuntu 22.04 LTS

References

Title

Publication Time

FKIE_CVE-2023-4134

Vulnerability from fkie_nvd - Published: 2024-11-14 11:15 - Updated: 2026-06-17 06:37

Severity

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

Summary

References

	URL	Tags
	patrick@puiterwijk.org	https://access.redhat.com/security/cve/CVE-2023-4134	Third Party Advisory
	patrick@puiterwijk.org	https://bugzilla.redhat.com/show_bug.cgi?id=2221700	Issue Tracking, Patch, Third Party Advisory

Impacted products

	Vendor	Product	Version
	linux	linux_kernel	*
	fedoraproject	fedora	38

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "collectionURL": "https://github.com/torvalds/linux",
          "packageName": "kernel",
          "repo": "https://github.com/torvalds/linux",
          "versions": [
            {
              "lessThan": "*",
              "status": "unaffected",
              "version": "dbe836576f12743a7d2d170ad4ad4fd324c4d47a",
              "versionType": "git"
            }
          ]
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:6"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel",
          "product": "Red Hat Enterprise Linux 6",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:7"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel",
          "product": "Red Hat Enterprise Linux 7",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:7"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel-rt",
          "product": "Red Hat Enterprise Linux 7",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:8"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel",
          "product": "Red Hat Enterprise Linux 8",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:8"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel-rt",
          "product": "Red Hat Enterprise Linux 8",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:9"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel",
          "product": "Red Hat Enterprise Linux 9",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/o:redhat:enterprise_linux:9"
          ],
          "defaultStatus": "unaffected",
          "packageName": "kernel-rt",
          "product": "Red Hat Enterprise Linux 9",
          "vendor": "Red Hat"
        }
      ],
      "source": "patrick@puiterwijk.org"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "98C491C7-598A-4D36-BA4F-3505A5727ED1",
              "versionEndExcluding": "6.5",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    },
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:fedoraproject:fedora:38:*:*:*:*:*:*:*",
              "matchCriteriaId": "CC559B26-5DFC-4B7A-A27C-B77DE755DFF9",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service."
    },
    {
      "lang": "es",
      "value": "Se encontr\u00f3 una vulnerabilidad de use-after-free en el controlador cyttsp4_core del kernel de Linux. Este problema se produce en la rutina de limpieza del dispositivo debido a un posible rearme del watchdog_timer desde la cola de trabajo. Esto podr\u00eda permitir que un usuario local bloquee el sistema, lo que provocar\u00eda una denegaci\u00f3n de servicio. "
    }
  ],
  "id": "CVE-2023-4134",
  "lastModified": "2026-06-17T06:37:09.330",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "patrick@puiterwijk.org",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2023-4134",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2024-11-14T18:53:48.023616Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-11-14T11:15:03.730",
  "references": [
    {
      "source": "patrick@puiterwijk.org",
      "tags": [
        "Third Party Advisory"
      ],
      "url": "https://access.redhat.com/security/cve/CVE-2023-4134"
    },
    {
      "source": "patrick@puiterwijk.org",
      "tags": [
        "Issue Tracking",
        "Patch",
        "Third Party Advisory"
      ],
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2221700"
    }
  ],
  "sourceIdentifier": "patrick@puiterwijk.org",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-416"
        }
      ],
      "source": "patrick@puiterwijk.org",
      "type": "Secondary"
    },
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-416"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

GHSA-HPVM-Q8V2-J94R

Vulnerability from github – Published: 2024-11-14 12:31 – Updated: 2024-11-14 12:31

Details

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-4134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-14T11:15:03Z",
    "severity": "MODERATE"
  },
  "details": "A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service.",
  "id": "GHSA-hpvm-q8v2-j94r",
  "modified": "2024-11-14T12:31:02Z",
  "published": "2024-11-14T12:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4134"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-4134"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2221700"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GSD-2023-4134

Vulnerability from gsd - Updated: 2023-12-13 01:20

Details

** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

Aliases

CVE-2023-4134

Aliases

CVE-2023-4134

JSON

To clipboard

{
  "GSD": {
    "alias": "CVE-2023-4134",
    "id": "GSD-2023-4134"
  },
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2023-4134"
      ],
      "id": "GSD-2023-4134",
      "modified": "2023-12-13T01:20:27.060272Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "cve@mitre.org",
        "ID": "CVE-2023-4134",
        "STATE": "RESERVED"
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided."
          }
        ]
      }
    }
  }
}

MSRC_CVE-2023-4134

Vulnerability from csaf_microsoft - Published: 2024-11-02 00:00 - Updated: 2026-03-31 14:37

Summary

Kernel: cyttsp4_core: use-after-free in cyttsp4_watchdog_work()

Scope

1 vulnerability in this advisory, including CVE-2023-4134.

CVE-2023-4134

Under investigation: 3 products

Open the full advisory

OESA-2024-2257 (CVE-2022-48688)

Vulnerability from osv_openeuler – Published: 2024-10-18 11:07 – Updated: 2026-08-06 11:07 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

i40e: Fix kernel crash during module removal

The driver incorrectly frees client instance and subsequent i40e module removal leads to kernel crash.

Reproducer: 1. Do ethtool offline test followed immediately by another one host# ethtool -t eth0 offline; ethtool -t eth0 offline 2. Remove recursively irdma module that also removes i40e module host# modprobe -r irdma

Result: [ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished [ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished [ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110 [ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2 [ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01 [ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1 [ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030 [ 8687.768755] #PF: supervisor read access in kernel mode [ 8687.773895] #PF: error_code(0x0000) - not-present page [ 8687.779034] PGD 0 P4D 0 [ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2 [ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019 [ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e] [ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b [ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202 [ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000 [ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000 [ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000 [ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0 [ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008 [ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000 [ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0 [ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8687.905572] PKRU: 55555554 [ 8687.908286] Call Trace: [ 8687.910737] <TASK> [ 8687.912843] i40e_remove+0x2c0/0x330 [i40e] [ 8687.917040] pci_device_remove+0x33/0xa0 [ 8687.920962] device_release_driver_internal+0x1aa/0x230 [ 8687.926188] driver_detach+0x44/0x90 [ 8687.929770] bus_remove_driver+0x55/0xe0 [ 8687.933693] pci_unregister_driver+0x2a/0xb0 [ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e]

Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this failure is indicated back to i40e_client_subtask() that calls i40e_client_del_instance() to free client instance referenced by pf->cinst and sets this pointer to NULL. During the module removal i40e_remove() calls i40e_lan_del_device() that dereferences pf->cinst that is NULL -> crash. Do not remove client instance when client open callbacks fails and just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs to take care about this situation (when netdev is up and client is NOT opened) in i40e_notify_client_of_netdev_close() and calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED is set.(CVE-2022-48688)

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

tracing/osnoise: Do not unregister events twice

Nicolas reported that using:

# trace-cmd record -e all -M 10 -p osnoise --poll

Resulted in the following kernel warning:

------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370 [...] CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19 RIP: 0010:tracepoint_probe_unregister+0x280/0x370 [...] CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0 Call Trace: <TASK> osnoise_workload_stop+0x36/0x90 tracing_set_tracer+0x108/0x260 tracing_set_trace_write+0x94/0xd0 ? __check_object_size.part.0+0x10a/0x150 ? selinux_file_permission+0x104/0x150 vfs_write+0xb5/0x290 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7ff919a18127 [...] ---[ end trace 0000000000000000 ]---

The warning complains about an attempt to unregister an unregistered tracepoint.

This happens on trace-cmd because it first stops tracing, and then switches the tracer to nop. Which is equivalent to:

# cd /sys/kernel/tracing/ # echo osnoise > current_tracer # echo 0 > tracing_on # echo nop > current_tracer

The osnoise tracer stops the workload when no trace instance is actually collecting data. This can be caused both by disabling tracing or disabling the tracer itself.

To avoid unregistering events twice, use the existing trace_osnoise_callback_enabled variable to check if the events (and the workload) are actually active before trying to deactivate them.(CVE-2022-48848)

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

USB: gadgetfs: Fix race between mounting and unmounting

The syzbot fuzzer and Gerald Lee have identified a use-after-free bug in the gadgetfs driver, involving processes concurrently mounting and unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super() can race with gadgetfs_kill_sb(), causing the latter to deallocate the_device while the former is using it. The output from KASAN says, in part:

BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline] BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline] BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline] BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline] BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline] BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline] BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689

CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> ... atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline] __refcount_sub_and_test include/linux/refcount.h:272 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] put_dev drivers/usb/gadget/legacy/inode.c:159 [inline] gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 vfs_get_super fs/super.c:1190 [inline] get_tree_single+0xd0/0x160 fs/super.c:1207 vfs_get_tree+0x88/0x270 fs/super.c:1531 vfs_fsconfig_locked fs/fsopen.c:232 [inline]

The simplest solution is to ensure that gadgetfs_fill_super() and gadgetfs_kill_sb() are serialized by making them both acquire a new mutex.(CVE-2022-48869)

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

efi: fix NULL-deref in init error path

In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated.

Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer.(CVE-2022-48879)

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

drm/i915/gt: Cleanup partial engine discovery failures

If we abort driver initialisation in the middle of gt/engine discovery, some engines will be fully setup and some not. Those incompletely setup engines only have 'engine->release == NULL' and so will leak any of the common objects allocated.

v2: - Drop the destroy_pinned_context() helper for now. It's not really worth it with just a single callsite at the moment. (Janusz)(CVE-2022-48893)

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

media: vivid: fix compose size exceed boundary

syzkaller found a bug:

BUG: unable to handle page fault for address: ffffc9000a3b1000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10 [...] Call Trace: <TASK> ? tpg_fill_plane_buffer+0x856/0x15b0 vivid_fillbuff+0x8ac/0x1110 vivid_thread_vid_cap_tick+0x361/0xc90 vivid_thread_vid_cap+0x21a/0x3a0 kthread+0x143/0x180 ret_from_fork+0x1f/0x30 </TASK>

This is because we forget to check boundary after adjust compose->height int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem for this case.(CVE-2022-48945)

A flaw possibility of memory leak in the Linux kernel cpu_entry_area mapping of X86 CPU data to memory was found in the way user can guess location of exception stack(s) or other important data. A local user could use this flaw to get access to some important data with expected location in memory.(CVE-2023-0597)

From the upstream fix below: The watchdog_timer can schedule tx_timeout_task and watchdog_work can also arm watchdog_timer [..] Although del_timer_sync() and cancel_work_sync() are called in cyttsp4_remove(), the timer and workqueue could still be rearmed. As a result, the possible use after free bugs could happen.

Upstream commit: https://github.com/torvalds/linux/commit/dbe836576f12743a7d2d170ad4ad4fd324c4d47a(CVE-2023-4134)

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

efivarfs: force RO when remounting if SetVariable is not supported

If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this:

$ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK

[ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]---

Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime.(CVE-2023-52463)

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

sched/psi: Fix use-after-free in ep_remove_wait_queue()

If a non-root cgroup gets removed when there is a thread that registered trigger and is polling on a pressure file within the cgroup, the polling waitqueue gets freed in the following path:

do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy

However, the polling thread still has a reference to the pressure file and will access the freed waitqueue when the file is closed or upon exit:

fput ep_eventpoll_release ep_free ep_remove_wait_queue remove_wait_queue

This results in use-after-free as pasted below.

The fundamental problem here is that cgroup_file_release() (and consequently waitqueue's lifetime) is not tied to the file's real lifetime. Using wake_up_pollfree() here might be less than ideal, but it is in line with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()") since the waitqueue's lifetime is not tied to file's one and can be considered as another special case. While this would be fixable by somehow making cgroup_file_release() be tied to the fput(), it would require sizable refactoring at cgroups or higher layer which might be more justifiable if we identify more cases like this.

BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0 Write of size 4 at addr ffff88810e625328 by task a.out/4404

CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38
Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
Call Trace:
&lt;TASK&gt;
dump_stack_lvl+0x73/0xa0
print_report+0x16c/0x4e0
kasan_report+0xc3/0xf0
kasan_check_range+0x2d2/0x310
_raw_spin_lock_irqsave+0x60/0xc0
remove_wait_queue+0x1a/0xa0
ep_free+0x12c/0x170
ep_eventpoll_release+0x26/0x30
__fput+0x202/0x400
task_work_run+0x11d/0x170
do_exit+0x495/0x1130
do_group_exit+0x100/0x100
get_signal+0xd67/0xde0
arch_do_signal_or_restart+0x2a/0x2b0
exit_to_user_mode_prepare+0x94/0x100
syscall_exit_to_user_mode+0x20/0x40
do_syscall_64+0x52/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
&lt;/TASK&gt;

Allocated by task 4404:

kasan_set_track+0x3d/0x60
__kasan_kmalloc+0x85/0x90
psi_trigger_create+0x113/0x3e0
pressure_write+0x146/0x2e0
cgroup_file_write+0x11c/0x250
kernfs_fop_write_iter+0x186/0x220
vfs_write+0x3d8/0x5c0
ksys_write+0x90/0x110
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 4407:

kasan_set_track+0x3d/0x60
kasan_save_free_info+0x27/0x40
____kasan_slab_free+0x11d/0x170
slab_free_freelist_hook+0x87/0x150
__kmem_cache_free+0xcb/0x180
psi_trigger_destroy+0x2e8/0x310
cgroup_file_release+0x4f/0xb0
kernfs_drain_open_files+0x165/0x1f0
kernfs_drain+0x162/0x1a0
__kernfs_remove+0x1fb/0x310
kernfs_remove_by_name_ns+0x95/0xe0
cgroup_addrm_files+0x67f/0x700
cgroup_destroy_locked+0x283/0x3c0
cgroup_rmdir+0x29/0x100
kernfs_iop_rmdir+0xd1/0x140
vfs_rmdir+0xfe/0x240
do_rmdir+0x13d/0x280
__x64_sys_rmdir+0x2c/0x30
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-52707)

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

cifs: Fix use-after-free in rdata->read_into_pages()

When the network status is unstable, use-after-free may occur when read data from the server.

BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0

Call Trace: <TASK> dump_stack_lvl+0x38/0x4c print_report+0x16f/0x4a6 kasan_report+0xb7/0x130 readpages_fill_pages+0x14c/0x7e0 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 </TASK>

Allocated by task 2535: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x82/0x90 cifs_readdata_direct_alloc+0x2c/0x110 cifs_readdata_alloc+0x2d/0x60 cifs_readahead+0x393/0xfe0 read_pages+0x12f/0x470 page_cache_ra_unbounded+0x1b1/0x240 filemap_get_pages+0x1c8/0x9a0 filemap_read+0x1c0/0x540 cifs_strict_readv+0x21b/0x240 vfs_read+0x395/0x4b0 ksys_read+0xb8/0x150 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Freed by task 79: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x50 __kasan_slab_free+0x10e/0x1a0 __kmem_cache_free+0x7a/0x1a0 cifs_readdata_release+0x49/0x60 process_one_work+0x46c/0x760 worker_thread+0x2a4/0x6f0 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50

Last potentially related work creation: kasan_save_stack+0x22/0x50 __kasan_record_aux_stack+0x95/0xb0 insert_work+0x2b/0x130 __queue_work+0x1fe/0x660 queue_work_on+0x4b/0x60 smb2_readv_callback+0x396/0x800 cifs_abort_connection+0x474/0x6a0 cifs_reconnect+0x5cb/0xa50 cifs_readv_from_socket.cold+0x22/0x6c cifs_read_page_from_socket+0xc1/0x100 readpages_fill_pages.cold+0x2f/0x46 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50

The following function calls will cause UAF of the rdata pointer.

readpages_fill_pages cifs_read_page_from_socket cifs_readv_from_socket cifs_reconnect __cifs_reconnect cifs_abort_connection mid->callback() --> smb2_readv_callback queue_work(&rdata->work) # if the worker completes first, # the rdata is freed cifs_readv_complete kref_put cifs_readdata_release kfree(rdata) return rdata->... # UAF in readpages_fill_pages()

Similarly, this problem also occurs in the uncache_fill_pages().

Fix this by adjusts the order of condition judgment in the return statement.(CVE-2023-52741)

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

tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc

Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway.

Require initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)

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

keys: Fix overwrite of key expiration on instantiation

The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry.(CVE-2024-36031)

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

ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()

In the following concurrency we will access the uninitialized rs->lock:

ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock __raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, RET_IP) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock here

and get the following dump_stack:

========================================================= INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] __ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4] [...] =========================================================

Normally interval is 0 until s_msg_ratelimit_state is initialized, so ___ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is uninitialized, and then a call to ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.(CVE-2024-40998)

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

bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()

set_memory_rox() can fail, leaving memory unprotected.

Check return and bail out when bpf_jit_binary_lock_ro() returns an error.(CVE-2024-42067)

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

net: nexthop: Initialize all fields in dumped nexthops

struct nexthop_grp contains two reserved fields that are not initialized by nla_put_nh_group(), and carry garbage. This can be observed e.g. with strace (edited for clarity):

# ip nexthop add id 1 dev lo
# ip nexthop add id 101 group 1
# strace -e recvmsg ip nexthop get id 101
...
recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},
             [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52

The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure.(CVE-2024-42283)

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

irqchip/imx-irqsteer: Handle runtime power management correctly

The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing:

BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0

Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context.

tglx: Rewrote change log, added Fixes tag

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

drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes

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

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

media: venus: fix use after free in vdec_close

There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst.

Fix it by cancelling the work in vdec_close.(CVE-2024-42313)

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

ipvs: properly dereference pe in ip_vs_add_service

Use pe directly to resolve sparse warning:

net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)

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

PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()

If IORESOURCE_MEM is not provided in Device Tree due to any error, resource_list_first_type() will return NULL and pci_parse_request_of_pci_ranges() will just emit a warning.

This will cause a NULL pointer dereference. Fix this bug by adding NULL return check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)

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

leds: trigger: Unregister sysfs attributes before calling deactivate()

Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback.

Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data.

Move the device_remove_groups() call to before deactivate() to close this race window.

This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups().(CVE-2024-43830)

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

md: fix deadlock between mddev_suspend and flush bio

Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue.

T1. the first flush is at the ending stage, it clears 'mddev->flush_bio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flush_bio', and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc active_io and tries to flush, but is blocked because 'mddev->flush_bio' is not NULL (set by T2). T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc by T3.

T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request . mddev->flush_bio = bio . queue submit_flushes . . . . md_handle_request . . active_io + 1 . . md_flush_request . . wait !mddev->flush_bio . . . . mddev_suspend . . wait !active_io . . . submit_flushes . queue_work md_submit_flush_data . //md_submit_flush_data is already running (T1) . md_handle_request wait resume

The root issue is non-atomic inc/dec of active_io during flush process. active_io is dec before md_submit_flush_data is queued, and inc soon after md_submit_flush_data() run. md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1

If active_io is dec after md_handle_request() instead of within submit_flushes(), make_request() can be called directly intead of md_handle_request() in md_submit_flush_data(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed.

Additionally, the only difference between fixing the issue and before is that there is no return error handling of make_request(). But after previous patch cleaned md_write_start(), make_requst() only return error in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, make_request() will not be called in md_submit_flush_data(). To prevent future modifications from introducing issues, add WARN_ON to ensure make_request() no error is returned in this context.(CVE-2024-43855)

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

memcg: protect concurrent access to mem_cgroup_idr

Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that.

We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases.

Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one.(CVE-2024-43892)

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

serial: core: check uartclk for zero to avoid divide by zero

Calling ioctl TIOCSSERIAL with an invalid baud_base can result in uartclk being zero, which will result in a divide by zero error in uart_get_divisor(). The check for uartclk being zero in uart_set_info() needs to be done before other settings are made as subsequent calls to ioctl TIOCSSERIAL for the same port would be impacted if the uartclk check was done where uartclk gets set.

Oops: divide error: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580) Call Trace: <TASK> serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576 drivers/tty/serial/8250/8250_port.c:2589) serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502 drivers/tty/serial/8250/8250_port.c:2741) serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862) uart_change_line_settings (./include/linux/spinlock.h:376 ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222) uart_port_startup (drivers/tty/serial/serial_core.c:342) uart_startup (drivers/tty/serial/serial_core.c:368) uart_set_info (drivers/tty/serial/serial_core.c:1034) uart_set_info_user (drivers/tty/serial/serial_core.c:1059) tty_set_serial (drivers/tty/tty_io.c:2637) tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791) __x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

Rule: add(CVE-2024-43893)

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

fou: remove warn in gue_gro_receive on unsupported protocol

Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler.

Such a packet is easily constructed. Syzbot generates them and sets off this warning.

Remove the warning as it is expected and not actionable.

The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks").(CVE-2024-44940)

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

atm: idt77252: prevent use after free in dequeue_rx()

We can't dereference "skb" after calling vcc->push() because the skb is released.(CVE-2024-44998)

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

xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration

re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference.

Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint().

On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware

If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth

[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c

Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated.(CVE-2024-45006)

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

s390/dasd: fix error recovery leading to data corruption on ESE devices

Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing.

The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format.

The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart.

Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode.

Also remove the check for file protected since this is not a valid ESE handling case.(CVE-2024-45026)

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

nfc: pn533: Add poll mod list filling check

In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero.

Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll()

Add poll mod list filling check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)

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

usb: typec: ucsi: Fix null pointer dereference in trace

ucsi_register_altmode checks IS_ERR for the alt pointer and treats NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled, ucsi_register_displayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typec_port_register_altmode to register DisplayPort alternate mode as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)

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

bpf: Remove tst_run from lwt_seg6local_prog_ops.

The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first.

Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it.

Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.(CVE-2024-46754)

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

ice: Add netif_device_attach/detach into PF reset flow

Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below.

Reproduction steps: Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net/<interface>/device/reset when reset is in progress try to get coalesce settings using ethtool: # ethtool -c <interface>

BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: <TASK> ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27

Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message:

netlink error: No such device

instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.(CVE-2024-46770)

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

ksmbd: unset the binding mark of a reused connection

Steve French reported null pointer dereference error from sha256 lib. cifs.ko can send session setup requests on reused connection. If reused connection is used for binding session, conn->binding can still remain true and generate_preauth_hash() will not set sess->Preauth_HashValue and it will be NULL. It is used as a material to create an encryption key in ksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer dereference error from crypto_shash_update().

BUG: kernel NULL pointer dereference, address: 0000000000000000

PF: supervisor read access in kernel mode

PF: error_code(0x0000) - not-present page

PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 8 PID: 429254 Comm: kworker/8:39 Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 ) Workqueue: ksmbd-io handle_ksmbd_work [ksmbd] RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3] <TASK> ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? do_user_addr_fault+0x2ee/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] ? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3] ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] _sha256_update+0x77/0xa0 [sha256_ssse3] sha256_avx2_update+0x15/0x30 [sha256_ssse3] crypto_shash_update+0x1e/0x40 hmac_update+0x12/0x20 crypto_shash_update+0x1e/0x40 generate_key+0x234/0x380 [ksmbd] generate_smb3encryptionkey+0x40/0x1c0 [ksmbd] ksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd] ntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd] smb2_sess_setup+0x952/0xaa0 [ksmbd] __process_request+0xa3/0x1d0 [ksmbd] __handle_ksmbd_work+0x1c4/0x2f0 [ksmbd] handle_ksmbd_work+0x2d/0xa0 [ksmbd] process_one_work+0x16c/0x350 worker_thread+0x306/0x440 ? __pfx_worker_thread+0x10/0x10 kthread+0xef/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x44/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK>(CVE-2024-46795)

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

drm/amdgpu: the warning dereferencing obj for nbio_v7_4

if ras_manager obj null, don't print NBIO err data(CVE-2024-46819)

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

sched: sch_cake: fix bulk flow accounting logic for host fairness

In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state.

This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again).

Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the increment was made conditional, but the decrement was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX).

AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right.

This patch fixes the issue by introducing the same conditional check on decrement as is used on increment.

The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that.(CVE-2024-46828)

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

btrfs: clean up our handling of refs == 0 in snapshot delete

In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.(CVE-2024-46840)

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

perf/x86/intel: Limit the period on Haswell

Running the ltp test cve-2015-3290 concurrently reports the following warnings.

perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330

Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)

The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW.

HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far.(CVE-2024-46848)

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

net: dpaa: Pad packets to ETH_ZLEN

When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running

$ ping -s 11 destination(CVE-2024-46854)

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

netfilter: nft_socket: fix sk refcount leaks

We must put 'sk' reference before returning.(CVE-2024-46855)

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

mptcp: pm: Fix uaf in __timer_delete_sync

There are two paths to access mptcp_pm_del_add_timer, result in a race condition:

 CPU1               CPU2
 ====                               ====
 net_rx_action
 napi_poll                          netlink_sendmsg
 __napi_poll                        netlink_unicast
 process_backlog                    netlink_unicast_kernel
 __netif_receive_skb                genl_rcv
 __netif_receive_skb_one_core       netlink_rcv_skb
 NF_HOOK                            genl_rcv_msg
 ip_local_deliver_finish            genl_family_rcv_msg
 ip_protocol_deliver_rcu            genl_family_rcv_msg_doit
 tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit
 tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list
 tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows
 tcp_data_queue                     remove_anno_list_by_saddr
 mptcp_incoming_options             mptcp_pm_del_add_timer
 mptcp_pm_del_add_timer             kfree(entry)

In remove_anno_list_by_saddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).

Keeping a reference to add_timer inside the lock, and calling sk_stop_timer_sync() with this reference, instead of "entry->add_timer".

Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf.(CVE-2024-46858)

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

crypto: stm32/cryp - call finalize with bh disabled

The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process.(CVE-2024-47658)

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

spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware

If the value of max_speed_hz is 0, it may cause a division by zero error in hisi_calc_effective_speed(). The value of max_speed_hz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of max_speed is validated here. So 0 is regarded as invalid and an error code is returned.(CVE-2024-47664)

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

ocfs2: add bounds checking to ocfs2_xattr_find_entry()

Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images.(CVE-2024-47670)

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

USB: usbtmc: prevent kernel-usb-infoleak

The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.(CVE-2024-47671)

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

wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead

There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead.

Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running.

edit commit message

Severity

9.8 (Critical)


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

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48688	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48848	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48869	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48879	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48893	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48945	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-0597	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-4134	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52463	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52707	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52741	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52880	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36031	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40998	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42067	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42283	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42290	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42309	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42313	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42322	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43823	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43830	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43855	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43892	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43893	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44940	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44998	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45006	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45026	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46676	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46719	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46754	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46770	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46795	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46819	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46828	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46840	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46848	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46854	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46855	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46858	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47658	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47664	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47670	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47671	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47672	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.97.0.178.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.97.0.178.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.97.0.178.oe2203sp1"
            }
          ],
          "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\ni40e: Fix kernel crash during module removal\r\n\r\nThe driver incorrectly frees client instance and subsequent\ni40e module removal leads to kernel crash.\r\n\r\nReproducer:\n1. Do ethtool offline test followed immediately by another one\nhost# ethtool -t eth0 offline; ethtool -t eth0 offline\n2. Remove recursively irdma module that also removes i40e module\nhost# modprobe -r irdma\r\n\r\nResult:\n[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting\n[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished\n[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting\n[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished\n[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110\n[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2\n[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01\n[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1\n[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[ 8687.768755] #PF: supervisor read access in kernel mode\n[ 8687.773895] #PF: error_code(0x0000) - not-present page\n[ 8687.779034] PGD 0 P4D 0\n[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G        W I        5.19.0+ #2\n[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019\n[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e]\n[ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb \u0026lt;48\u0026gt; 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b\n[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202\n[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000\n[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000\n[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000\n[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0\n[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008\n[ 8687.870342] FS:  00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000\n[ 8687.878427] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0\n[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 8687.905572] PKRU: 55555554\n[ 8687.908286] Call Trace:\n[ 8687.910737]  \u0026lt;TASK\u0026gt;\n[ 8687.912843]  i40e_remove+0x2c0/0x330 [i40e]\n[ 8687.917040]  pci_device_remove+0x33/0xa0\n[ 8687.920962]  device_release_driver_internal+0x1aa/0x230\n[ 8687.926188]  driver_detach+0x44/0x90\n[ 8687.929770]  bus_remove_driver+0x55/0xe0\n[ 8687.933693]  pci_unregister_driver+0x2a/0xb0\n[ 8687.937967]  i40e_exit_module+0xc/0xf48 [i40e]\r\n\r\nTwo offline tests cause IRDMA driver failure (ETIMEDOUT) and this\nfailure is indicated back to i40e_client_subtask() that calls\ni40e_client_del_instance() to free client instance referenced\nby pf-\u0026gt;cinst and sets this pointer to NULL. During the module\nremoval i40e_remove() calls i40e_lan_del_device() that dereferences\npf-\u0026gt;cinst that is NULL -\u0026gt; crash.\nDo not remove client instance when client open callbacks fails and\njust clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs\nto take care about this situation (when netdev is up and client\nis NOT opened) in i40e_notify_client_of_netdev_close() and\ncalls client close callback only when __I40E_CLIENT_INSTANCE_OPENED\nis set.(CVE-2022-48688)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing/osnoise: Do not unregister events twice\r\n\r\nNicolas reported that using:\r\n\r\n # trace-cmd record -e all -M 10 -p osnoise --poll\r\n\r\nResulted in the following kernel warning:\r\n\r\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370\n [...]\n CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19\n RIP: 0010:tracepoint_probe_unregister+0x280/0x370\n [...]\n CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  osnoise_workload_stop+0x36/0x90\n  tracing_set_tracer+0x108/0x260\n  tracing_set_trace_write+0x94/0xd0\n  ? __check_object_size.part.0+0x10a/0x150\n  ? selinux_file_permission+0x104/0x150\n  vfs_write+0xb5/0x290\n  ksys_write+0x5f/0xe0\n  do_syscall_64+0x3b/0x90\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7ff919a18127\n [...]\n ---[ end trace 0000000000000000 ]---\r\n\r\nThe warning complains about an attempt to unregister an\nunregistered tracepoint.\r\n\r\nThis happens on trace-cmd because it first stops tracing, and\nthen switches the tracer to nop. Which is equivalent to:\r\n\r\n  # cd /sys/kernel/tracing/\n  # echo osnoise \u0026gt; current_tracer\n  # echo 0 \u0026gt; tracing_on\n  # echo nop \u0026gt; current_tracer\r\n\r\nThe osnoise tracer stops the workload when no trace instance\nis actually collecting data. This can be caused both by\ndisabling tracing or disabling the tracer itself.\r\n\r\nTo avoid unregistering events twice, use the existing\ntrace_osnoise_callback_enabled variable to check if the events\n(and the workload) are actually active before trying to\ndeactivate them.(CVE-2022-48848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: gadgetfs: Fix race between mounting and unmounting\r\n\r\nThe syzbot fuzzer and Gerald Lee have identified a use-after-free bug\nin the gadgetfs driver, involving processes concurrently mounting and\nunmounting the gadgetfs filesystem.  In particular, gadgetfs_fill_super()\ncan race with gadgetfs_kill_sb(), causing the latter to deallocate\nthe_device while the former is using it.  The output from KASAN says,\nin part:\r\n\r\nBUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]\nBUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]\nBUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]\nBUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]\nBUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]\nBUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]\nBUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086\nWrite of size 4 at addr ffff8880276d7840 by task syz-executor126/18689\r\n\r\nCPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nCall Trace:\n \u0026lt;TASK\u0026gt;\n...\n atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]\n __refcount_sub_and_test include/linux/refcount.h:272 [inline]\n __refcount_dec_and_test include/linux/refcount.h:315 [inline]\n refcount_dec_and_test include/linux/refcount.h:333 [inline]\n put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]\n gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086\n deactivate_locked_super+0xa7/0xf0 fs/super.c:332\n vfs_get_super fs/super.c:1190 [inline]\n get_tree_single+0xd0/0x160 fs/super.c:1207\n vfs_get_tree+0x88/0x270 fs/super.c:1531\n vfs_fsconfig_locked fs/fsopen.c:232 [inline]\r\n\r\nThe simplest solution is to ensure that gadgetfs_fill_super() and\ngadgetfs_kill_sb() are serialized by making them both acquire a new\nmutex.(CVE-2022-48869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi: fix NULL-deref in init error path\r\n\r\nIn cases where runtime services are not supported or have been disabled,\nthe runtime services workqueue will never have been allocated.\r\n\r\nDo not try to destroy the workqueue unconditionally in the unlikely\nevent that EFI initialisation fails to avoid dereferencing a NULL\npointer.(CVE-2022-48879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Cleanup partial engine discovery failures\r\n\r\nIf we abort driver initialisation in the middle of gt/engine discovery,\nsome engines will be fully setup and some not. Those incompletely setup\nengines only have \u0026apos;engine-\u0026gt;release == NULL\u0026apos; and so will leak any of the\ncommon objects allocated.\r\n\r\nv2:\n - Drop the destroy_pinned_context() helper for now.  It\u0026apos;s not really\n   worth it with just a single callsite at the moment.  (Janusz)(CVE-2022-48893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vivid: fix compose size exceed boundary\r\n\r\nsyzkaller found a bug:\r\n\r\n BUG: unable to handle page fault for address: ffffc9000a3b1000\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0\n Oops: 0002 [#1] PREEMPT SMP\n CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n RIP: 0010:memcpy_erms+0x6/0x10\n[...]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? tpg_fill_plane_buffer+0x856/0x15b0\n  vivid_fillbuff+0x8ac/0x1110\n  vivid_thread_vid_cap_tick+0x361/0xc90\n  vivid_thread_vid_cap+0x21a/0x3a0\n  kthread+0x143/0x180\n  ret_from_fork+0x1f/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because we forget to check boundary after adjust compose-\u0026gt;height\nint V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem\nfor this case.(CVE-2022-48945)\r\n\r\nA flaw possibility of memory leak in the Linux kernel cpu_entry_area mapping of X86 CPU data to memory was found in the way user can guess location of exception stack(s) or other important data. A local user could use this flaw to get access to some important data with expected location in memory.(CVE-2023-0597)\r\n\r\nFrom the upstream fix below: The watchdog_timer can schedule tx_timeout_task and watchdog_work can also arm watchdog_timer [..] Although del_timer_sync() and cancel_work_sync() are called in cyttsp4_remove(), the timer and workqueue could still be rearmed. As a result, the possible use after free bugs could happen.\r\n\r\nUpstream commit:\nhttps://github.com/torvalds/linux/commit/dbe836576f12743a7d2d170ad4ad4fd324c4d47a(CVE-2023-4134)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefivarfs: force RO when remounting if SetVariable is not supported\r\n\r\nIf SetVariable at runtime is not supported by the firmware we never assign\na callback for that function. At the same time mount the efivarfs as\nRO so no one can call that.  However, we never check the permission flags\nwhen someone remounts the filesystem as RW. As a result this leads to a\ncrash looking like this:\r\n\r\n$ mount -o remount,rw /sys/firmware/efi/efivars\n$ efi-updatevar -f PK.auth PK\r\n\r\n[  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[  303.280482] Mem abort info:\n[  303.280854]   ESR = 0x0000000086000004\n[  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits\n[  303.282016]   SET = 0, FnV = 0\n[  303.282414]   EA = 0, S1PTW = 0\n[  303.282821]   FSC = 0x04: level 0 translation fault\n[  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000\n[  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP\n[  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6\n[  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1\n[  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023\n[  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  303.292123] pc : 0x0\n[  303.292443] lr : efivar_set_variable_locked+0x74/0xec\n[  303.293156] sp : ffff800008673c10\n[  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000\n[  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027\n[  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000\n[  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000\n[  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54\n[  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4\n[  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002\n[  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201\n[  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc\n[  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000\n[  303.303341] Call trace:\n[  303.303679]  0x0\n[  303.303938]  efivar_entry_set_get_size+0x98/0x16c\n[  303.304585]  efivarfs_file_write+0xd0/0x1a4\n[  303.305148]  vfs_write+0xc4/0x2e4\n[  303.305601]  ksys_write+0x70/0x104\n[  303.306073]  __arm64_sys_write+0x1c/0x28\n[  303.306622]  invoke_syscall+0x48/0x114\n[  303.307156]  el0_svc_common.constprop.0+0x44/0xec\n[  303.307803]  do_el0_svc+0x38/0x98\n[  303.308268]  el0_svc+0x2c/0x84\n[  303.308702]  el0t_64_sync_handler+0xf4/0x120\n[  303.309293]  el0t_64_sync+0x190/0x194\n[  303.309794] Code: ???????? ???????? ???????? ???????? (????????)\n[  303.310612] ---[ end trace 0000000000000000 ]---\r\n\r\nFix this by adding a .reconfigure() function to the fs operations which\nwe can use to check the requested flags and deny anything that\u0026apos;s not RO\nif the firmware doesn\u0026apos;t implement SetVariable at runtime.(CVE-2023-52463)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/psi: Fix use-after-free in ep_remove_wait_queue()\r\n\r\nIf a non-root cgroup gets removed when there is a thread that registered\ntrigger and is polling on a pressure file within the cgroup, the polling\nwaitqueue gets freed in the following path:\r\n\r\n do_rmdir\n   cgroup_rmdir\n     kernfs_drain_open_files\n       cgroup_file_release\n         cgroup_pressure_release\n           psi_trigger_destroy\r\n\r\nHowever, the polling thread still has a reference to the pressure file and\nwill access the freed waitqueue when the file is closed or upon exit:\r\n\r\n fput\n   ep_eventpoll_release\n     ep_free\n       ep_remove_wait_queue\n         remove_wait_queue\r\n\r\nThis results in use-after-free as pasted below.\r\n\r\nThe fundamental problem here is that cgroup_file_release() (and\nconsequently waitqueue\u0026apos;s lifetime) is not tied to the file\u0026apos;s real lifetime.\nUsing wake_up_pollfree() here might be less than ideal, but it is in line\nwith the comment at commit 42288cb44c4b (\u0026quot;wait: add wake_up_pollfree()\u0026quot;)\nsince the waitqueue\u0026apos;s lifetime is not tied to file\u0026apos;s one and can be\nconsidered as another special case. While this would be fixable by somehow\nmaking cgroup_file_release() be tied to the fput(), it would require\nsizable refactoring at cgroups or higher layer which might be more\njustifiable if we identify more cases like this.\r\n\r\n  BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0\n  Write of size 4 at addr ffff88810e625328 by task a.out/4404\r\n\r\n\tCPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38\n\tHardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017\n\tCall Trace:\n\t\u0026lt;TASK\u0026gt;\n\tdump_stack_lvl+0x73/0xa0\n\tprint_report+0x16c/0x4e0\n\tkasan_report+0xc3/0xf0\n\tkasan_check_range+0x2d2/0x310\n\t_raw_spin_lock_irqsave+0x60/0xc0\n\tremove_wait_queue+0x1a/0xa0\n\tep_free+0x12c/0x170\n\tep_eventpoll_release+0x26/0x30\n\t__fput+0x202/0x400\n\ttask_work_run+0x11d/0x170\n\tdo_exit+0x495/0x1130\n\tdo_group_exit+0x100/0x100\n\tget_signal+0xd67/0xde0\n\tarch_do_signal_or_restart+0x2a/0x2b0\n\texit_to_user_mode_prepare+0x94/0x100\n\tsyscall_exit_to_user_mode+0x20/0x40\n\tdo_syscall_64+0x52/0x90\n\tentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\t\u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 4404:\r\n\r\n\tkasan_set_track+0x3d/0x60\n\t__kasan_kmalloc+0x85/0x90\n\tpsi_trigger_create+0x113/0x3e0\n\tpressure_write+0x146/0x2e0\n\tcgroup_file_write+0x11c/0x250\n\tkernfs_fop_write_iter+0x186/0x220\n\tvfs_write+0x3d8/0x5c0\n\tksys_write+0x90/0x110\n\tdo_syscall_64+0x43/0x90\n\tentry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\n Freed by task 4407:\r\n\r\n\tkasan_set_track+0x3d/0x60\n\tkasan_save_free_info+0x27/0x40\n\t____kasan_slab_free+0x11d/0x170\n\tslab_free_freelist_hook+0x87/0x150\n\t__kmem_cache_free+0xcb/0x180\n\tpsi_trigger_destroy+0x2e8/0x310\n\tcgroup_file_release+0x4f/0xb0\n\tkernfs_drain_open_files+0x165/0x1f0\n\tkernfs_drain+0x162/0x1a0\n\t__kernfs_remove+0x1fb/0x310\n\tkernfs_remove_by_name_ns+0x95/0xe0\n\tcgroup_addrm_files+0x67f/0x700\n\tcgroup_destroy_locked+0x283/0x3c0\n\tcgroup_rmdir+0x29/0x100\n\tkernfs_iop_rmdir+0xd1/0x140\n\tvfs_rmdir+0xfe/0x240\n\tdo_rmdir+0x13d/0x280\n\t__x64_sys_rmdir+0x2c/0x30\n\tdo_syscall_64+0x43/0x90\n\tentry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-52707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncifs: Fix use-after-free in rdata-\u0026gt;read_into_pages()\r\n\r\nWhen the network status is unstable, use-after-free may occur when\nread data from the server.\r\n\r\n  BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0\r\n\r\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x38/0x4c\n   print_report+0x16f/0x4a6\n   kasan_report+0xb7/0x130\n   readpages_fill_pages+0x14c/0x7e0\n   cifs_readv_receive+0x46d/0xa40\n   cifs_demultiplex_thread+0x121c/0x1490\n   kthread+0x16b/0x1a0\n   ret_from_fork+0x2c/0x50\n   \u0026lt;/TASK\u0026gt;\r\n\r\n  Allocated by task 2535:\n   kasan_save_stack+0x22/0x50\n   kasan_set_track+0x25/0x30\n   __kasan_kmalloc+0x82/0x90\n   cifs_readdata_direct_alloc+0x2c/0x110\n   cifs_readdata_alloc+0x2d/0x60\n   cifs_readahead+0x393/0xfe0\n   read_pages+0x12f/0x470\n   page_cache_ra_unbounded+0x1b1/0x240\n   filemap_get_pages+0x1c8/0x9a0\n   filemap_read+0x1c0/0x540\n   cifs_strict_readv+0x21b/0x240\n   vfs_read+0x395/0x4b0\n   ksys_read+0xb8/0x150\n   do_syscall_64+0x3f/0x90\n   entry_SYSCALL_64_after_hwframe+0x72/0xdc\r\n\r\n  Freed by task 79:\n   kasan_save_stack+0x22/0x50\n   kasan_set_track+0x25/0x30\n   kasan_save_free_info+0x2e/0x50\n   __kasan_slab_free+0x10e/0x1a0\n   __kmem_cache_free+0x7a/0x1a0\n   cifs_readdata_release+0x49/0x60\n   process_one_work+0x46c/0x760\n   worker_thread+0x2a4/0x6f0\n   kthread+0x16b/0x1a0\n   ret_from_fork+0x2c/0x50\r\n\r\n  Last potentially related work creation:\n   kasan_save_stack+0x22/0x50\n   __kasan_record_aux_stack+0x95/0xb0\n   insert_work+0x2b/0x130\n   __queue_work+0x1fe/0x660\n   queue_work_on+0x4b/0x60\n   smb2_readv_callback+0x396/0x800\n   cifs_abort_connection+0x474/0x6a0\n   cifs_reconnect+0x5cb/0xa50\n   cifs_readv_from_socket.cold+0x22/0x6c\n   cifs_read_page_from_socket+0xc1/0x100\n   readpages_fill_pages.cold+0x2f/0x46\n   cifs_readv_receive+0x46d/0xa40\n   cifs_demultiplex_thread+0x121c/0x1490\n   kthread+0x16b/0x1a0\n   ret_from_fork+0x2c/0x50\r\n\r\nThe following function calls will cause UAF of the rdata pointer.\r\n\r\nreadpages_fill_pages\n cifs_read_page_from_socket\n  cifs_readv_from_socket\n   cifs_reconnect\n    __cifs_reconnect\n     cifs_abort_connection\n      mid-\u0026gt;callback() --\u0026gt; smb2_readv_callback\n       queue_work(\u0026amp;rdata-\u0026gt;work)  # if the worker completes first,\n                                 # the rdata is freed\n          cifs_readv_complete\n            kref_put\n              cifs_readdata_release\n                kfree(rdata)\n return rdata-\u0026gt;...               # UAF in readpages_fill_pages()\r\n\r\nSimilarly, this problem also occurs in the uncache_fill_pages().\r\n\r\nFix this by adjusts the order of condition judgment in the return\nstatement.(CVE-2023-52741)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\r\n\r\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\r\n\r\nRequire initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkeys: Fix overwrite of key expiration on instantiation\r\n\r\nThe expiry time of a key is unconditionally overwritten during\ninstantiation, defaulting to turn it permanent. This causes a problem\nfor DNS resolution as the expiration set by user-space is overwritten to\nTIME64_MAX, disabling further DNS updates. Fix this by restoring the\ncondition that key_set_expiry is only called when the pre-parser sets a\nspecific expiry.(CVE-2024-36031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix uninitialized ratelimit_state-\u0026gt;lock access in __ext4_fill_super()\r\n\r\nIn the following concurrency we will access the uninitialized rs-\u0026gt;lock:\r\n\r\next4_fill_super\n  ext4_register_sysfs\n   // sysfs registered msg_ratelimit_interval_ms\n                             // Other processes modify rs-\u0026gt;interval to\n                             // non-zero via msg_ratelimit_interval_ms\n  ext4_orphan_cleanup\n    ext4_msg(sb, KERN_INFO, \u0026quot;Errors on filesystem, \u0026quot;\n      __ext4_msg\n        ___ratelimit(\u0026amp;(EXT4_SB(sb)-\u0026gt;s_msg_ratelimit_state)\n          if (!rs-\u0026gt;interval)  // do nothing if interval is 0\n            return 1;\n          raw_spin_trylock_irqsave(\u0026amp;rs-\u0026gt;lock, flags)\n            raw_spin_trylock(lock)\n              _raw_spin_trylock\n                __raw_spin_trylock\n                  spin_acquire(\u0026amp;lock-\u0026gt;dep_map, 0, 1, _RET_IP_)\n                    lock_acquire\n                      __lock_acquire\n                        register_lock_class\n                          assign_lock_key\n                            dump_stack();\n  ratelimit_state_init(\u0026amp;sbi-\u0026gt;s_msg_ratelimit_state, 5 * HZ, 10);\n    raw_spin_lock_init(\u0026amp;rs-\u0026gt;lock);\n    // init rs-\u0026gt;lock here\r\n\r\nand get the following dump_stack:\r\n\r\n=========================================================\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0026apos;t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504\n[...]\nCall Trace:\n dump_stack_lvl+0xc5/0x170\n dump_stack+0x18/0x30\n register_lock_class+0x740/0x7c0\n __lock_acquire+0x69/0x13a0\n lock_acquire+0x120/0x450\n _raw_spin_trylock+0x98/0xd0\n ___ratelimit+0xf6/0x220\n __ext4_msg+0x7f/0x160 [ext4]\n ext4_orphan_cleanup+0x665/0x740 [ext4]\n __ext4_fill_super+0x21ea/0x2b10 [ext4]\n ext4_fill_super+0x14d/0x360 [ext4]\n[...]\n=========================================================\r\n\r\nNormally interval is 0 until s_msg_ratelimit_state is initialized, so\n___ratelimit() does nothing. But registering sysfs precedes initializing\nrs-\u0026gt;lock, so it is possible to change rs-\u0026gt;interval to a non-zero value\nvia the msg_ratelimit_interval_ms interface of sysfs while rs-\u0026gt;lock is\nuninitialized, and then a call to ext4_msg triggers the problem by\naccessing an uninitialized rs-\u0026gt;lock. Therefore register sysfs after all\ninitializations are complete to avoid such problems.(CVE-2024-40998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\r\n\r\nset_memory_rox() can fail, leaving memory unprotected.\r\n\r\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.(CVE-2024-42067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nexthop: Initialize all fields in dumped nexthops\r\n\r\nstruct nexthop_grp contains two reserved fields that are not initialized by\nnla_put_nh_group(), and carry garbage. This can be observed e.g. with\nstrace (edited for clarity):\r\n\r\n    # ip nexthop add id 1 dev lo\n    # ip nexthop add id 101 group 1\n    # strace -e recvmsg ip nexthop get id 101\n    ...\n    recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},\n                 [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52\r\n\r\nThe fields are reserved and therefore not currently used. But as they are, they\nleak kernel memory, and the fact they are not just zero complicates repurposing\nof the fields for new ends. Initialize the full structure.(CVE-2024-42283)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nirqchip/imx-irqsteer: Handle runtime power management correctly\r\n\r\nThe power domain is automatically activated from clk_prepare(). However, on\ncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes\nsleeping functions, which triggers the \u0026apos;scheduling while atomic\u0026apos; bug in the\ncontext switch path during device probing:\r\n\r\n BUG: scheduling while atomic: kworker/u13:1/48/0x00000002\n Call trace:\n  __schedule_bug+0x54/0x6c\n  __schedule+0x7f0/0xa94\n  schedule+0x5c/0xc4\n  schedule_preempt_disabled+0x24/0x40\n  __mutex_lock.constprop.0+0x2c0/0x540\n  __mutex_lock_slowpath+0x14/0x20\n  mutex_lock+0x48/0x54\n  clk_prepare_lock+0x44/0xa0\n  clk_prepare+0x20/0x44\n  imx_irqsteer_resume+0x28/0xe0\n  pm_generic_runtime_resume+0x2c/0x44\n  __genpd_runtime_resume+0x30/0x80\n  genpd_runtime_resume+0xc8/0x2c0\n  __rpm_callback+0x48/0x1d8\n  rpm_callback+0x6c/0x78\n  rpm_resume+0x490/0x6b4\n  __pm_runtime_resume+0x50/0x94\n  irq_chip_pm_get+0x2c/0xa0\n  __irq_do_set_handler+0x178/0x24c\n  irq_set_chained_handler_and_data+0x60/0xa4\n  mxc_gpio_probe+0x160/0x4b0\r\n\r\nCure this by implementing the irq_bus_lock/sync_unlock() interrupt chip\ncallbacks and handle power management in them as they are invoked from\nnon-atomic context.\r\n\r\n[ tglx: Rewrote change log, added Fixes tag ](CVE-2024-42290)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes\r\n\r\nIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42309)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: venus: fix use after free in vdec_close\r\n\r\nThere appears to be a possible use after free with vdec_close().\nThe firmware will add buffer release work to the work queue through\nHFI callbacks as a normal part of decoding. Randomly closing the\ndecoder device from userspace during normal decoding can incur\na read after free for inst.\r\n\r\nFix it by cancelling the work in vdec_close.(CVE-2024-42313)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvs: properly dereference pe in ip_vs_add_service\r\n\r\nUse pe directly to resolve sparse warning:\r\n\r\n  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()\r\n\r\nIf IORESOURCE_MEM is not provided in Device Tree due to\nany error, resource_list_first_type() will return NULL and\npci_parse_request_of_pci_ranges() will just emit a warning.\r\n\r\nThis will cause a NULL pointer dereference. Fix this bug by adding NULL\nreturn check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: trigger: Unregister sysfs attributes before calling deactivate()\r\n\r\nTriggers which have trigger specific sysfs attributes typically store\nrelated data in trigger-data allocated by the activate() callback and\nfreed by the deactivate() callback.\r\n\r\nCalling device_remove_groups() after calling deactivate() leaves a window\nwhere the sysfs attributes show/store functions could be called after\ndeactivation and then operate on the just freed trigger-data.\r\n\r\nMove the device_remove_groups() call to before deactivate() to close\nthis race window.\r\n\r\nThis also makes the deactivation path properly do things in reverse order\nof the activation path which calls the activate() callback before calling\ndevice_add_groups().(CVE-2024-43830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix deadlock between mddev_suspend and flush bio\r\n\r\nDeadlock occurs when mddev is being suspended while some flush bio is in\nprogress. It is a complex issue.\r\n\r\nT1. the first flush is at the ending stage, it clears \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;\n    and tries to submit data, but is blocked because mddev is suspended\n    by T4.\nT2. the second flush sets \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;, and attempts to queue\n    md_submit_flush_data(), which is already running (T1) and won\u0026apos;t\n    execute again if on the same CPU as T1.\nT3. the third flush inc active_io and tries to flush, but is blocked because\n    \u0026apos;mddev-\u0026gt;flush_bio\u0026apos; is not NULL (set by T2).\nT4. mddev_suspend() is called and waits for active_io dec to 0 which is inc\n    by T3.\r\n\r\n  T1\t\tT2\t\tT3\t\tT4\n  (flush 1)\t(flush 2)\t(third 3)\t(suspend)\n  md_submit_flush_data\n   mddev-\u0026gt;flush_bio = NULL;\n   .\n   .\t \tmd_flush_request\n   .\t  \t mddev-\u0026gt;flush_bio = bio\n   .\t  \t queue submit_flushes\n   .\t\t .\n   .\t\t .\t\tmd_handle_request\n   .\t\t .\t\t active_io + 1\n   .\t\t .\t\t md_flush_request\n   .\t\t .\t\t  wait !mddev-\u0026gt;flush_bio\n   .\t\t .\n   .\t\t .\t\t\t\tmddev_suspend\n   .\t\t .\t\t\t\t wait !active_io\n   .\t\t .\n   .\t\t submit_flushes\n   .\t\t queue_work md_submit_flush_data\n   .\t\t //md_submit_flush_data is already running (T1)\n   .\n   md_handle_request\n    wait resume\r\n\r\nThe root issue is non-atomic inc/dec of active_io during flush process.\nactive_io is dec before md_submit_flush_data is queued, and inc soon\nafter md_submit_flush_data() run.\n  md_flush_request\n    active_io + 1\n    submit_flushes\n      active_io - 1\n      md_submit_flush_data\n        md_handle_request\n        active_io + 1\n          make_request\n        active_io - 1\r\n\r\nIf active_io is dec after md_handle_request() instead of within\nsubmit_flushes(), make_request() can be called directly intead of\nmd_handle_request() in md_submit_flush_data(), and active_io will\nonly inc and dec once in the whole flush process. Deadlock will be\nfixed.\r\n\r\nAdditionally, the only difference between fixing the issue and before is\nthat there is no return error handling of make_request(). But after\nprevious patch cleaned md_write_start(), make_requst() only return error\nin raid5_make_request() by dm-raid, see commit 41425f96d7aa (\u0026quot;dm-raid456,\nmd/raid456: fix a deadlock for dm-raid456 while io concurrent with\nreshape)\u0026quot;. Since dm always splits data and flush operation into two\nseparate io, io size of flush submitted by dm always is 0, make_request()\nwill not be called in md_submit_flush_data(). To prevent future\nmodifications from introducing issues, add WARN_ON to ensure\nmake_request() no error is returned in this context.(CVE-2024-43855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg: protect concurrent access to mem_cgroup_idr\r\n\r\nCommit 73f576c04b94 (\u0026quot;mm: memcontrol: fix cgroup creation failure after\nmany small jobs\u0026quot;) decoupled the memcg IDs from the CSS ID space to fix the\ncgroup creation failures.  It introduced IDR to maintain the memcg ID\nspace.  The IDR depends on external synchronization mechanisms for\nmodifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()\nhappen within css callback and thus are protected through cgroup_mutex\nfrom concurrent modifications.  However idr_remove() for mem_cgroup_idr\nwas not protected against concurrency and can be run concurrently for\ndifferent memcgs when they hit their refcnt to zero.  Fix that.\r\n\r\nWe have been seeing list_lru based kernel crashes at a low frequency in\nour fleet for a long time.  These crashes were in different part of\nlist_lru code including list_lru_add(), list_lru_del() and reparenting\ncode.  Upon further inspection, it looked like for a given object (dentry\nand inode), the super_block\u0026apos;s list_lru didn\u0026apos;t have list_lru_one for the\nmemcg of that object.  The initial suspicions were either the object is\nnot allocated through kmem_cache_alloc_lru() or somehow\nmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but\nreturned success.  No evidence were found for these cases.\r\n\r\nLooking more deeply, we started seeing situations where valid memcg\u0026apos;s id\nis not present in mem_cgroup_idr and in some cases multiple valid memcgs\nhave same id and mem_cgroup_idr is pointing to one of them.  So, the most\nreasonable explanation is that these situations can happen due to race\nbetween multiple idr_remove() calls or race between\nidr_alloc()/idr_replace() and idr_remove().  These races are causing\nmultiple memcgs to acquire the same ID and then offlining of one of them\nwould cleanup list_lrus on the system for all of them.  Later access from\nother memcgs to the list_lru cause crashes due to missing list_lru_one.(CVE-2024-43892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: core: check uartclk for zero to avoid divide by zero\r\n\r\nCalling ioctl TIOCSSERIAL with an invalid baud_base can\nresult in uartclk being zero, which will result in a\ndivide by zero error in uart_get_divisor(). The check for\nuartclk being zero in uart_set_info() needs to be done\nbefore other settings are made as subsequent calls to\nioctl TIOCSSERIAL for the same port would be impacted if\nthe uartclk check was done where uartclk gets set.\r\n\r\nOops: divide error: 0000  PREEMPT SMP KASAN PTI\nRIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)\nCall Trace:\n \u0026lt;TASK\u0026gt;\nserial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576\n    drivers/tty/serial/8250/8250_port.c:2589)\nserial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502\n    drivers/tty/serial/8250/8250_port.c:2741)\nserial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)\nuart_change_line_settings (./include/linux/spinlock.h:376\n    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)\nuart_port_startup (drivers/tty/serial/serial_core.c:342)\nuart_startup (drivers/tty/serial/serial_core.c:368)\nuart_set_info (drivers/tty/serial/serial_core.c:1034)\nuart_set_info_user (drivers/tty/serial/serial_core.c:1059)\ntty_set_serial (drivers/tty/tty_io.c:2637)\ntty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)\n__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907\n    fs/ioctl.c:893 fs/ioctl.c:893)\ndo_syscall_64 (arch/x86/entry/common.c:52\n    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nRule: add(CVE-2024-43893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfou: remove warn in gue_gro_receive on unsupported protocol\r\n\r\nDrop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is\nnot known or does not have a GRO handler.\r\n\r\nSuch a packet is easily constructed. Syzbot generates them and sets\noff this warning.\r\n\r\nRemove the warning as it is expected and not actionable.\r\n\r\nThe warning was previously reduced from WARN_ON to WARN_ON_ONCE in\ncommit 270136613bf7 (\u0026quot;fou: Do WARN_ON_ONCE in gue_gro_receive for bad\nproto callbacks\u0026quot;).(CVE-2024-44940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natm: idt77252: prevent use after free in dequeue_rx()\r\n\r\nWe can\u0026apos;t dereference \u0026quot;skb\u0026quot; after calling vcc-\u0026gt;push() because the skb\nis released.(CVE-2024-44998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix Panther point NULL pointer deref at full-speed re-enumeration\r\n\r\nre-enumerating full-speed devices after a failed address device command\ncan trigger a NULL pointer dereference.\r\n\r\nFull-speed devices may need to reconfigure the endpoint 0 Max Packet Size\nvalue during enumeration. Usb core calls usb_ep0_reinit() in this case,\nwhich ends up calling xhci_configure_endpoint().\r\n\r\nOn Panther point xHC the xhci_configure_endpoint() function will\nadditionally check and reserve bandwidth in software. Other hosts do\nthis in hardware\r\n\r\nIf xHC address device command fails then a new xhci_virt_device structure\nis allocated as part of re-enabling the slot, but the bandwidth table\npointers are not set up properly here.\nThis triggers the NULL pointer dereference the next time usb_ep0_reinit()\nis called and xhci_configure_endpoint() tries to check and reserve\nbandwidth\r\n\r\n[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd\n[46710.713699] usb 3-1: Device not responding to setup address.\n[46710.917684] usb 3-1: Device not responding to setup address.\n[46711.125536] usb 3-1: device not accepting address 5, error -71\n[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[46711.125600] #PF: supervisor read access in kernel mode\n[46711.125603] #PF: error_code(0x0000) - not-present page\n[46711.125606] PGD 0 P4D 0\n[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI\n[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1\n[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.\n[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]\n[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c\r\n\r\nFix this by making sure bandwidth table pointers are set up correctly\nafter a failed address device command, and additionally by avoiding\nchecking for bandwidth in cases like this where no actual endpoints are\nadded or removed, i.e. only context for default control endpoint 0 is\nevaluated.(CVE-2024-45006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix error recovery leading to data corruption on ESE devices\r\n\r\nExtent Space Efficient (ESE) or thin provisioned volumes need to be\nformatted on demand during usual IO processing.\r\n\r\nThe dasd_ese_needs_format function checks for error codes that signal\nthe non existence of a proper track format.\r\n\r\nThe check for incorrect length is to imprecise since other error cases\nleading to transport of insufficient data also have this flag set.\nThis might lead to data corruption in certain error cases for example\nduring a storage server warmstart.\r\n\r\nFix by removing the check for incorrect length and replacing by\nexplicitly checking for invalid track format in transport mode.\r\n\r\nAlso remove the check for file protected since this is not a valid\nESE handling case.(CVE-2024-45026)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: pn533: Add poll mod list filling check\r\n\r\nIn case of im_protocols value is 1 and tm_protocols value is 0 this\ncombination successfully passes the check\n\u0026apos;if (!im_protocols \u0026amp;\u0026amp; !tm_protocols)\u0026apos; in the nfc_start_poll().\nBut then after pn533_poll_create_mod_list() call in pn533_start_poll()\npoll mod list will remain empty and dev-\u0026gt;poll_mod_count will remain 0\nwhich lead to division by zero.\r\n\r\nNormally no im protocol has value 1 in the mask, so this combination is\nnot expected by driver. But these protocol values actually come from\nuserspace via Netlink interface (NFC_CMD_START_POLL operation). So a\nbroken or malicious program may pass a message containing a \u0026quot;bad\u0026quot;\ncombination of protocol parameter values so that dev-\u0026gt;poll_mod_count\nis not incremented inside pn533_poll_create_mod_list(), thus leading\nto division by zero.\nCall trace looks like:\nnfc_genl_start_poll()\n  nfc_start_poll()\n    -\u0026gt;start_poll()\n    pn533_start_poll()\r\n\r\nAdd poll mod list filling check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: ucsi: Fix null pointer dereference in trace\r\n\r\nucsi_register_altmode checks IS_ERR for the alt pointer and treats\nNULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,\nucsi_register_displayport returns NULL which causes a NULL pointer\ndereference in trace. Rather than return NULL, call\ntypec_port_register_altmode to register DisplayPort alternate mode\nas a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Remove tst_run from lwt_seg6local_prog_ops.\r\n\r\nThe syzbot reported that the lwt_seg6 related BPF ops can be invoked\nvia bpf_test_run() without without entering input_action_end_bpf()\nfirst.\r\n\r\nMartin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL\nprobably didn\u0026apos;t work since it was introduced in commit 04d4b274e2a\n(\u0026quot;ipv6: sr: Add seg6local action End.BPF\u0026quot;). The reason is that the\nper-CPU variable seg6_bpf_srh_states::srh is never assigned in the self\ntest case but each BPF function expects it.\r\n\r\nRemove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.(CVE-2024-46754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Add netif_device_attach/detach into PF reset flow\r\n\r\nEthtool callbacks can be executed while reset is in progress and try to\naccess deleted resources, e.g. getting coalesce settings can result in a\nNULL pointer dereference seen below.\r\n\r\nReproduction steps:\nOnce the driver is fully initialized, trigger reset:\n\t# echo 1 \u0026gt; /sys/class/net/\u0026lt;interface\u0026gt;/device/reset\nwhen reset is in progress try to get coalesce settings using ethtool:\n\t# ethtool -c \u0026lt;interface\u0026gt;\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000020\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP PTI\nCPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7\nRIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]\nRSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206\nRAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000\nR13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40\nFS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0\nCall Trace:\n\u0026lt;TASK\u0026gt;\nice_get_coalesce+0x17/0x30 [ice]\ncoalesce_prepare_data+0x61/0x80\nethnl_default_doit+0xde/0x340\ngenl_family_rcv_msg_doit+0xf2/0x150\ngenl_rcv_msg+0x1b3/0x2c0\nnetlink_rcv_skb+0x5b/0x110\ngenl_rcv+0x28/0x40\nnetlink_unicast+0x19c/0x290\nnetlink_sendmsg+0x222/0x490\n__sys_sendto+0x1df/0x1f0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x82/0x160\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7faee60d8e27\r\n\r\nCalling netif_device_detach() before reset makes the net core not call\nthe driver when ethtool command is issued, the attempt to execute an\nethtool command during reset will result in the following message:\r\n\r\n    netlink error: No such device\r\n\r\ninstead of NULL pointer dereference. Once reset is done and\nice_rebuild() is executing, the netif_device_attach() is called to allow\nfor ethtool operations to occur again in a safe manner.(CVE-2024-46770)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: unset the binding mark of a reused connection\r\n\r\nSteve French reported null pointer dereference error from sha256 lib.\ncifs.ko can send session setup requests on reused connection.\nIf reused connection is used for binding session, conn-\u0026gt;binding can\nstill remain true and generate_preauth_hash() will not set\nsess-\u0026gt;Preauth_HashValue and it will be NULL.\nIt is used as a material to create an encryption key in\nksmbd_gen_smb311_encryptionkey. -\u0026gt;Preauth_HashValue cause null pointer\ndereference error from crypto_shash_update().\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 8 PID: 429254 Comm: kworker/8:39\nHardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )\nWorkqueue: ksmbd-io handle_ksmbd_work [ksmbd]\nRIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n\u0026lt;TASK\u0026gt;\n? show_regs+0x6d/0x80\n? __die+0x24/0x80\n? page_fault_oops+0x99/0x1b0\n? do_user_addr_fault+0x2ee/0x6b0\n? exc_page_fault+0x83/0x1b0\n? asm_exc_page_fault+0x27/0x30\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n_sha256_update+0x77/0xa0 [sha256_ssse3]\nsha256_avx2_update+0x15/0x30 [sha256_ssse3]\ncrypto_shash_update+0x1e/0x40\nhmac_update+0x12/0x20\ncrypto_shash_update+0x1e/0x40\ngenerate_key+0x234/0x380 [ksmbd]\ngenerate_smb3encryptionkey+0x40/0x1c0 [ksmbd]\nksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]\nntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]\nsmb2_sess_setup+0x952/0xaa0 [ksmbd]\n__process_request+0xa3/0x1d0 [ksmbd]\n__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]\nhandle_ksmbd_work+0x2d/0xa0 [ksmbd]\nprocess_one_work+0x16c/0x350\nworker_thread+0x306/0x440\n? __pfx_worker_thread+0x10/0x10\nkthread+0xef/0x120\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x44/0x70\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1b/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2024-46795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: the warning dereferencing obj for nbio_v7_4\r\n\r\nif ras_manager obj null, don\u0026apos;t print NBIO err data(CVE-2024-46819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched: sch_cake: fix bulk flow accounting logic for host fairness\r\n\r\nIn sch_cake, we keep track of the count of active bulk flows per host,\nwhen running in dst/src host fairness mode, which is used as the\nround-robin weight when iterating through flows. The count of active\nbulk flows is updated whenever a flow changes state.\r\n\r\nThis has a peculiar interaction with the hash collision handling: when a\nhash collision occurs (after the set-associative hashing), the state of\nthe hash bucket is simply updated to match the new packet that collided,\nand if host fairness is enabled, that also means assigning new per-host\nstate to the flow. For this reason, the bulk flow counters of the\nhost(s) assigned to the flow are decremented, before new state is\nassigned (and the counters, which may not belong to the same host\nanymore, are incremented again).\r\n\r\nBack when this code was introduced, the host fairness mode was always\nenabled, so the decrement was unconditional. When the configuration\nflags were introduced the *increment* was made conditional, but\nthe *decrement* was not. Which of course can lead to a spurious\ndecrement (and associated wrap-around to U16_MAX).\r\n\r\nAFAICT, when host fairness is disabled, the decrement and wrap-around\nhappens as soon as a hash collision occurs (which is not that common in\nitself, due to the set-associative hashing). However, in most cases this\nis harmless, as the value is only used when host fairness mode is\nenabled. So in order to trigger an array overflow, sch_cake has to first\nbe configured with host fairness disabled, and while running in this\nmode, a hash collision has to occur to cause the overflow. Then, the\nqdisc has to be reconfigured to enable host fairness, which leads to the\narray out-of-bounds because the wrapped-around value is retained and\nused as an array index. It seems that syzbot managed to trigger this,\nwhich is quite impressive in its own right.\r\n\r\nThis patch fixes the issue by introducing the same conditional check on\ndecrement as is used on increment.\r\n\r\nThe original bug predates the upstreaming of cake, but the commit listed\nin the Fixes tag touched that code, meaning that this patch won\u0026apos;t apply\nbefore that.(CVE-2024-46828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: clean up our handling of refs == 0 in snapshot delete\r\n\r\nIn reada we BUG_ON(refs == 0), which could be unkind since we aren\u0026apos;t\nholding a lock on the extent leaf and thus could get a transient\nincorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which\ncould happen if we have extent tree corruption.  Change that to return\n-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,\nhowever we return -EIO, which -EUCLEAN is a more appropriate error code.\nFinally in walk_up_proc we have the same BUG_ON(refs == 0), so convert\nthat to proper error handling.  Also adjust the error message so we can\nactually do something with the information.(CVE-2024-46840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/x86/intel: Limit the period on Haswell\r\n\r\nRunning the ltp test cve-2015-3290 concurrently reports the following\nwarnings.\r\n\r\nperfevents: irq loop stuck!\n  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174\n  intel_pmu_handle_irq+0x285/0x370\n  Call Trace:\n   \u0026lt;NMI\u0026gt;\n   ? __warn+0xa4/0x220\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? __report_bug+0x123/0x130\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? __report_bug+0x123/0x130\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? report_bug+0x3e/0xa0\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x50\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? irq_work_claim+0x1e/0x40\n   ? intel_pmu_handle_irq+0x285/0x370\n   perf_event_nmi_handler+0x3d/0x60\n   nmi_handle+0x104/0x330\r\n\r\nThanks to Thomas Gleixner\u0026apos;s analysis, the issue is caused by the low\ninitial period (1) of the frequency estimation algorithm, which triggers\nthe defects of the HW, specifically erratum HSW11 and HSW143. (For the\ndetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)\r\n\r\nThe HSW11 requires a period larger than 100 for the INST_RETIRED.ALL\nevent, but the initial period in the freq mode is 1. The erratum is the\nsame as the BDM11, which has been supported in the kernel. A minimum\nperiod of 128 is enforced as well on HSW.\r\n\r\nHSW143 is regarding that the fixed counter 1 may overcount 32 with the\nHyper-Threading is enabled. However, based on the test, the hardware\nhas more issues than it tells. Besides the fixed counter 1, the message\n\u0026apos;interrupt took too long\u0026apos; can be observed on any counter which was armed\nwith a period \u0026lt; 32 and two events expired in the same NMI. A minimum\nperiod of 32 is enforced for the rest of the events.\nThe recommended workaround code of the HSW143 is not implemented.\nBecause it only addresses the issue for the fixed counter. It brings\nextra overhead through extra MSR writing. No related overcounting issue\nhas been reported so far.(CVE-2024-46848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dpaa: Pad packets to ETH_ZLEN\r\n\r\nWhen sending packets under 60 bytes, up to three bytes of the buffer\nfollowing the data may be leaked. Avoid this by extending all packets to\nETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be\nreproduced by running\r\n\r\n\t$ ping -s 11 destination(CVE-2024-46854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_socket: fix sk refcount leaks\r\n\r\nWe must put \u0026apos;sk\u0026apos; reference before returning.(CVE-2024-46855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: Fix uaf in __timer_delete_sync\r\n\r\nThere are two paths to access mptcp_pm_del_add_timer, result in a race\ncondition:\r\n\r\n     CPU1\t\t\t\tCPU2\n     ====                               ====\n     net_rx_action\n     napi_poll                          netlink_sendmsg\n     __napi_poll                        netlink_unicast\n     process_backlog                    netlink_unicast_kernel\n     __netif_receive_skb                genl_rcv\n     __netif_receive_skb_one_core       netlink_rcv_skb\n     NF_HOOK                            genl_rcv_msg\n     ip_local_deliver_finish            genl_family_rcv_msg\n     ip_protocol_deliver_rcu            genl_family_rcv_msg_doit\n     tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit\n     tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list\n     tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows\n     tcp_data_queue                     remove_anno_list_by_saddr\n     mptcp_incoming_options             mptcp_pm_del_add_timer\n     mptcp_pm_del_add_timer             kfree(entry)\r\n\r\nIn remove_anno_list_by_saddr(running on CPU2), after leaving the critical\nzone protected by \u0026quot;pm.lock\u0026quot;, the entry will be released, which leads to the\noccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).\r\n\r\nKeeping a reference to add_timer inside the lock, and calling\nsk_stop_timer_sync() with this reference, instead of \u0026quot;entry-\u0026gt;add_timer\u0026quot;.\r\n\r\nMove list_del(\u0026amp;entry-\u0026gt;list) to mptcp_pm_del_add_timer and inside the pm lock,\ndo not directly access any members of the entry outside the pm lock, which\ncan avoid similar \u0026quot;entry-\u0026gt;x\u0026quot; uaf.(CVE-2024-46858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: stm32/cryp - call finalize with bh disabled\r\n\r\nThe finalize operation in interrupt mode produce a produces a spinlock\nrecursion warning. The reason is the fact that BH must be disabled\nduring this process.(CVE-2024-47658)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware\r\n\r\nIf the value of max_speed_hz is 0, it may cause a division by zero\nerror in hisi_calc_effective_speed().\nThe value of max_speed_hz is provided by firmware.\nFirmware is generally considered as a trusted domain. However, as\ndivision by zero errors can cause system failure, for defense measure,\nthe value of max_speed is validated here. So 0 is regarded as invalid\nand an error code is returned.(CVE-2024-47664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_xattr_find_entry()\r\n\r\nAdd a paranoia check to make sure it doesn\u0026apos;t stray beyond valid memory\nregion containing ocfs2 xattr entries when scanning for a match.  It will\nprevent out-of-bound access in case of crafted images.(CVE-2024-47670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usbtmc: prevent kernel-usb-infoleak\r\n\r\nThe syzbot reported a kernel-usb-infoleak in usbtmc_write,\nwe need to clear the structure before filling fields.(CVE-2024-47671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: don\u0026apos;t wait for tx queues if firmware is dead\r\n\r\nThere is a WARNING in iwl_trans_wait_tx_queues_empty() (that was\nrecently converted from just a message), that can be hit if we\nwait for TX queues to become empty after firmware died. Clearly,\nwe can\u0026apos;t expect anything from the firmware after it\u0026apos;s declared dead.\r\n\r\nDon\u0026apos;t call iwl_trans_wait_tx_queues_empty() in this case. While it could\nbe a good idea to stop the flow earlier, the flush functions do some\nmaintenance work that is not related to the firmware, so keep that part\nof the code running even when the firmware is not running.\r\n\r\n[edit commit message](CVE-2024-47672)",
  "id": "OESA-2024-2257",
  "modified": "2026-08-06T11:07:44Z",
  "published": "2024-10-18T11:07:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2257"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48688"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48848"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48869"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48893"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48945"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0597"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4134"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52463"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52707"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52741"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52880"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36031"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40998"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42067"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42283"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42290"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42309"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42313"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42322"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43823"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43830"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43855"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43892"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43893"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44940"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44998"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45006"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45026"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46676"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46719"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46754"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46770"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46795"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46819"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46840"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46848"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46854"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46855"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46858"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47658"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47664"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47670"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47671"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47672"
    }
  ],
  "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-48688",
    "CVE-2022-48848",
    "CVE-2022-48869",
    "CVE-2022-48879",
    "CVE-2022-48893",
    "CVE-2022-48945",
    "CVE-2023-0597",
    "CVE-2023-4134",
    "CVE-2023-52463",
    "CVE-2023-52707",
    "CVE-2023-52741",
    "CVE-2023-52880",
    "CVE-2024-36031",
    "CVE-2024-40998",
    "CVE-2024-42067",
    "CVE-2024-42283",
    "CVE-2024-42290",
    "CVE-2024-42309",
    "CVE-2024-42313",
    "CVE-2024-42322",
    "CVE-2024-43823",
    "CVE-2024-43830",
    "CVE-2024-43855",
    "CVE-2024-43892",
    "CVE-2024-43893",
    "CVE-2024-44940",
    "CVE-2024-44998",
    "CVE-2024-45006",
    "CVE-2024-45026",
    "CVE-2024-46676",
    "CVE-2024-46719",
    "CVE-2024-46754",
    "CVE-2024-46770",
    "CVE-2024-46795",
    "CVE-2024-46819",
    "CVE-2024-46828",
    "CVE-2024-46840",
    "CVE-2024-46848",
    "CVE-2024-46854",
    "CVE-2024-46855",
    "CVE-2024-46858",
    "CVE-2024-47658",
    "CVE-2024-47664",
    "CVE-2024-47670",
    "CVE-2024-47671",
    "CVE-2024-47672"
  ]
}

OPENSUSE-SU-2024:13179-1

Vulnerability from csaf_opensuse - Published: 2024-06-15 00:00 - Updated: 2026-09-20 20:55

Summary

kernel-devel-6.4.12-1.1 on GA media

Severity

Moderate

Scope

1 vulnerability in this advisory, including CVE-2023-4134.

CVE-2023-4134

4.1 (Medium)


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

Recommended: 16 products

Open the full advisory

OPENSUSE-SU-2024:13704-1

Vulnerability from csaf_opensuse - Published: 2024-06-15 00:00 - Updated: 2026-10-11 11:54

Summary

kernel-devel-longterm-6.6.17-1.1 on GA media

Severity

Moderate

Scope

194 vulnerabilities in this advisory, including CVE-2023-4134.

CVE-2023-4134

4.1 (Medium)


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

Recommended: 8 products

Open the full advisory

SUSE-SU-2023:3599-1

Vulnerability from csaf_suse - Published: 2023-09-21 10:18 - Updated: 2026-09-20 15:20

Summary

Security update for the Linux Kernel

Severity

Important

Scope

20 vulnerabilities in this advisory, including CVE-2023-4134.

CVE-2023-4134

4.1 (Medium)


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

Recommended: 1 product

Open the full advisory

SUSE-SU-2023:3599-2

Vulnerability from csaf_suse - Published: 2023-09-21 10:18 - Updated: 2026-09-20 15:20

Summary

Security update for the Linux Kernel

Severity

Important

Scope

20 vulnerabilities in this advisory, including CVE-2023-4134.

CVE-2023-4134

4.1 (Medium)


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

Recommended: 1 product

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

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

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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

Related by attack behaviour

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

Action not permitted

CVE-2023-4134 (GCVE-0-2023-4134)

Solution

OESA-2024-2257 (CVE-2022-48688)

PF: supervisor read access in kernel mode

PF: error_code(0x0000) - not-present page

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour