{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/ubifs/file.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "4aa554832b9dc9e66249df75b8f447d87853e12e",
              "status": "affected",
              "version": "1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d",
              "versionType": "git"
            },
            {
              "lessThan": "778c6ad40256f1c03244fc06d7cdf71f6b5e7310",
              "status": "affected",
              "version": "1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d",
              "versionType": "git"
            },
            {
              "lessThan": "8f599ab6fabbca4c741107eade70722a98adfd9f",
              "status": "affected",
              "version": "1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d",
              "versionType": "git"
            },
            {
              "lessThan": "f19b1023a3758f40791ec166038d6411c8894ae3",
              "status": "affected",
              "version": "1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d",
              "versionType": "git"
            },
            {
              "lessThan": "142d87c958d9454c3cffa625fab56f3016e8f9f3",
              "status": "affected",
              "version": "1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d",
              "versionType": "git"
            },
            {
              "lessThan": "fc99f4e2d2f1ce766c14e98463c2839194ae964f",
              "status": "affected",
              "version": "1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d",
              "versionType": "git"
            },
            {
              "lessThan": "4b7c4fc60d6a46350fbe54f5dc937aeaa02e675e",
              "status": "affected",
              "version": "1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d",
              "versionType": "git"
            },
            {
              "lessThan": "17772bbe9cfa972ea1ff827319f6e1340de76566",
              "status": "affected",
              "version": "1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d",
              "versionType": "git"
            },
            {
              "lessThan": "723012cab779eee8228376754e22c6594229bf8f",
              "status": "affected",
              "version": "1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/ubifs/file.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.27"
            },
            {
              "lessThan": "2.6.27",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.312",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.274",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.215",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.154",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.84",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.24",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.7.*",
              "status": "unaffected",
              "version": "6.7.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.9",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "affectedData": [
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "4aa554832b9d",
              "status": "affected",
              "version": "1e51764a3c2a",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "778c6ad40256",
              "status": "affected",
              "version": "1e51764a3c2a",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "8f599ab6fabb",
              "status": "affected",
              "version": "1e51764a3c2a",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "f19b1023a375",
              "status": "affected",
              "version": "1e51764a3c2a",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "142d87c958d9",
              "status": "affected",
              "version": "1e51764a3c2a",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "fc99f4e2d2f1",
              "status": "affected",
              "version": "1e51764a3c2a",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "4b7c4fc60d6a",
              "status": "affected",
              "version": "1e51764a3c2a",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "17772bbe9cfa",
              "status": "affected",
              "version": "1e51764a3c2a",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "723012cab779",
              "status": "affected",
              "version": "1e51764a3c2a",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.27"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThan": "2.6.27",
              "status": "unaffected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.312",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.274",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.215",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.154",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.84",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.24",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThanOrEqual": "6.7.*",
              "status": "unaffected",
              "version": "6.7.12",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.3",
              "versionType": "custom"
            }
          ]
        },
        {
          "cpes": [
            "cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "linux_kernel",
          "vendor": "linux",
          "versions": [
            {
              "status": "unaffected",
              "version": "6.9"
            }
          ]
        }
      ],
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
              "matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    },
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "390386D8-59A9-413F-A27B-DA960BBD9287",
              "versionEndExcluding": "4.19.312",
              "versionStartIncluding": "2.6.27",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "F45A0F3C-C16D-49C4-86D6-D021C3D4B834",
              "versionEndExcluding": "5.4.274",
              "versionStartIncluding": "4.20",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "9CD5894E-58E9-4B4A-B0F4-3E6BC134B8F5",
              "versionEndExcluding": "5.10.215",
              "versionStartIncluding": "5.5",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "577E212E-7E95-4A71-9B5C-F1D1A3AFFF46",
              "versionEndExcluding": "5.15.154",
              "versionStartIncluding": "5.11",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "834D9BD5-42A6-4D74-979E-4D6D93F630FD",
              "versionEndExcluding": "6.1.84",
              "versionStartIncluding": "5.16",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "8018C1D0-0A5F-48D0-BC72-A2B33FDDA693",
              "versionEndExcluding": "6.6.24",
              "versionStartIncluding": "6.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "6BE9771A-BAFD-4624-95F9-58D536540C53",
              "versionEndExcluding": "6.7.12",
              "versionStartIncluding": "6.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "4C59BBC3-6495-4A77-9C82-55EC7CDF5E02",
              "versionEndExcluding": "6.8.3",
              "versionStartIncluding": "6.8",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Set page uptodate in the correct place\n\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we\u0027ve overwritten it with the data it\u0027s supposed to have\nin it will allow a simultaneous reader to see old data.  Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page."
    },
    {
      "lang": "es",
      "value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: establece la actualizaci\u00f3n de la p\u00e1gina en el lugar correcto. Las lecturas de la cach\u00e9 de la p\u00e1gina no tienen bloqueo, por lo que configurar la actualizaci\u00f3n de la p\u00e1gina reci\u00e9n asignada antes de que la sobrescribamos con los datos que se supone que debe contener lo har\u00e1. permitir que un lector simult\u00e1neo vea datos antiguos. Mueva la llamada a SetPageUptodate a ubifs_write_end(), que es despu\u00e9s de que copiamos los nuevos datos en la p\u00e1gina."
    }
  ],
  "id": "CVE-2024-35821",
  "lastModified": "2026-06-17T07:35:28.820",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 7.5,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 3.6,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2024-35821",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2025-01-23T21:47:42.750475Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-05-17T14:15:17.373",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/17772bbe9cfa972ea1ff827319f6e1340de76566"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa02e675e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/723012cab779eee8228376754e22c6594229bf8f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/17772bbe9cfa972ea1ff827319f6e1340de76566"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa02e675e"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/723012cab779eee8228376754e22c6594229bf8f"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Third Party Advisory"
      ],
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Third Party Advisory"
      ],
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "NVD-CWE-noinfo"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    },
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-772"
        }
      ],
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-35821"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-772"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T14:15:17Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Set page uptodate in the correct place\n\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we\u0027ve overwritten it with the data it\u0027s supposed to have\nin it will allow a simultaneous reader to see old data.  Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page.",
  "id": "GHSA-vf5r-hx7h-7rvc",
  "modified": "2024-07-03T18:42:25Z",
  "published": "2024-05-17T15:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35821"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/17772bbe9cfa972ea1ff827319f6e1340de76566"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa02e675e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/723012cab779eee8228376754e22c6594229bf8f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "python3-perf-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "bpftool-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2406.3.0.0282.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "python3-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "bpftool-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2406.3.0.0282.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: aardvark: Fix kernel panic during PIO transfer\r\n\r\nTrying to start a new PIO transfer by writing value 0 in PIO_START register\nwhen previous transfer has not yet completed (which is indicated by value 1\nin PIO_START) causes an External Abort on CPU, which results in kernel\npanic:\r\n\r\n    SError Interrupt on CPU0, code 0xbf000002 -- SError\n    Kernel panic - not syncing: Asynchronous SError Interrupt\r\n\r\nTo prevent kernel panic, it is required to reject a new PIO transfer when\nprevious one has not finished yet.\r\n\r\nIf previous PIO transfer is not finished yet, the kernel may issue a new\nPIO request only if the previous PIO transfer timed out.\r\n\r\nIn the past the root cause of this issue was incorrectly identified (as it\noften happens during link retraining or after link down event) and special\nhack was implemented in Trusted Firmware to catch all SError events in EL3,\nto ignore errors with code 0xbf000002 and not forwarding any other errors\nto kernel and instead throw panic from EL3 Trusted Firmware handler.\r\n\r\nLinks to discussion and patches about this issue:\nhttps://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50\nhttps://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/\nhttps://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/\nhttps://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541\r\n\r\nBut the real cause was the fact that during link retraining or after link\ndown event the PIO transfer may take longer time, up to the 1.44s until it\ntimes out. This increased probability that a new PIO transfer would be\nissued by kernel while previous one has not finished yet.\r\n\r\nAfter applying this change into the kernel, it is possible to revert the\nmentioned TF-A hack and SError events do not have to be caught in TF-A EL3.(CVE-2021-47229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()\r\n\r\nUse clk_disable_unprepare() in the error path of mtk_phy_init() to fix\nsome resource leaks.(CVE-2021-47234)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: rds: fix memory leak in rds_recvmsg\r\n\r\nSyzbot reported memory leak in rds. The problem\nwas in unputted refcount in case of error.\r\n\r\nint rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,\n\t\tint msg_flags)\n{\n...\r\n\r\n\tif (!rds_next_incoming(rs, \u0026amp;inc)) {\n\t\t...\n\t}\r\n\r\nAfter this \u0026quot;if\u0026quot; inc refcount incremented and\r\n\r\n\tif (rds_cmsg_recv(inc, msg, rs)) {\n\t\tret = -EFAULT;\n\t\tgoto out;\n\t}\n...\nout:\n\treturn ret;\n}\r\n\r\nin case of rds_cmsg_recv() fail the refcount won\u0026apos;t be\ndecremented. And it\u0026apos;s easy to see from ftrace log, that\nrds_inc_addref() don\u0026apos;t have rds_inc_put() pair in\nrds_recvmsg() after rds_cmsg_recv()\r\n\r\n 1)               |  rds_recvmsg() {\n 1)   3.721 us    |    rds_inc_addref();\n 1)   3.853 us    |    rds_message_inc_copy_to_user();\n 1) + 10.395 us   |    rds_cmsg_recv();\n 1) + 34.260 us   |  }(CVE-2021-47249)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ieee802154: fix null deref in parse dev addr\r\n\r\nFix a logic error that could result in a null deref if the user sets\nthe mode incorrectly for the given addr type.(CVE-2021-47257)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: fix various gadget panics on 10gbps cabling\r\n\r\nusb_assign_descriptors() is called with 5 parameters,\nthe last 4 of which are the usb_descriptor_header for:\n  full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),\n  high-speed (USB2.0 - 480Mbps),\n  super-speed (USB3.0 - 5Gbps),\n  super-speed-plus (USB3.1 - 10Gbps).\r\n\r\nThe differences between full/high/super-speed descriptors are usually\nsubstantial (due to changes in the maximum usb block size from 64 to 512\nto 1024 bytes and other differences in the specs), while the difference\nbetween 5 and 10Gbps descriptors may be as little as nothing\n(in many cases the same tuning is simply good enough).\r\n\r\nHowever if a gadget driver calls usb_assign_descriptors() with\na NULL descriptor for super-speed-plus and is then used on a max 10gbps\nconfiguration, the kernel will crash with a null pointer dereference,\nwhen a 10gbps capable device port + cable + host port combination shows up.\n(This wouldn\u0026apos;t happen if the gadget max-speed was set to 5gbps, but\nit of course defaults to the maximum, and there\u0026apos;s no real reason to\nartificially limit it)\r\n\r\nThe fix is to simply use the 5gbps descriptor as the 10gbps descriptor,\nif a 10gbps descriptor wasn\u0026apos;t provided.\r\n\r\nObviously this won\u0026apos;t fix the problem if the 5gbps descriptor is also\nNULL, but such cases can\u0026apos;t be so trivially solved (and any such gadgets\nare unlikely to be used with USB3 ports any way).(CVE-2021-47267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: seq: Fix race of snd_seq_timer_open()\r\n\r\nThe timer instance per queue is exclusive, and snd_seq_timer_open()\nshould have managed the concurrent accesses.  It looks as if it\u0026apos;s\nchecking the already existing timer instance at the beginning, but\nit\u0026apos;s not right, because there is no protection, hence any later\nconcurrent call of snd_seq_timer_open() may override the timer\ninstance easily.  This may result in UAF, as the leftover timer\ninstance can keep running while the queue itself gets closed, as\nspotted by syzkaller recently.\r\n\r\nFor avoiding the race, add a proper check at the assignment of\ntmr-\u0026gt;timeri again, and return -EBUSY if it\u0026apos;s been already registered.(CVE-2021-47281)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nigb: Fix use-after-free error during reset\r\n\r\nCleans the next descriptor to watch (next_to_watch) when cleaning the\nTX ring.\r\n\r\nFailure to do so can cause invalid memory accesses. If igb_poll() runs\nwhile the controller is reset this can lead to the driver try to free\na skb that was already freed.\r\n\r\n(The crash is harder to reproduce with the igb driver, but the same\npotential problem exists as the code is identical to igc)(CVE-2021-47301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ti: fix UAF in tlan_remove_one\r\n\r\npriv is netdev private data and it cannot be\nused after free_netdev() call. Using priv after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.(CVE-2021-47310)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: Fix possible use-after-free by calling del_timer_sync()\r\n\r\nThis driver\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47321)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmisc/libmasm/module: Fix two use after free in ibmasm_init_one\r\n\r\nIn ibmasm_init_one, it calls ibmasm_init_remote_input_dev().\nInside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are\nallocated by input_allocate_device(), and assigned to\nsp-\u0026gt;remote.mouse_dev and sp-\u0026gt;remote.keybd_dev respectively.\r\n\r\nIn the err_free_devices error branch of ibmasm_init_one,\nmouse_dev and keybd_dev are freed by input_free_device(), and return\nerror. Then the execution runs into error_send_message error branch\nof ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called\nto unregister the freed sp-\u0026gt;remote.mouse_dev and sp-\u0026gt;remote.keybd_dev.\r\n\r\nMy patch add a \u0026quot;error_init_remote\u0026quot; label to handle the error of\nibmasm_init_remote_input_dev(), to avoid the uaf bugs.(CVE-2021-47334)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: zr364xx: fix memory leak in zr364xx_start_readpipe\r\n\r\nsyzbot reported memory leak in zr364xx driver.\nThe problem was in non-freed urb in case of\nusb_submit_urb() fail.\r\n\r\nbacktrace:\n  [\u0026lt;ffffffff82baedf6\u0026gt;] kmalloc include/linux/slab.h:561 [inline]\n  [\u0026lt;ffffffff82baedf6\u0026gt;] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74\n  [\u0026lt;ffffffff82f7cce8\u0026gt;] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022\n  [\u0026lt;ffffffff84251dfc\u0026gt;] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]\n  [\u0026lt;ffffffff84251dfc\u0026gt;] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516\n  [\u0026lt;ffffffff82bb6507\u0026gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396\n  [\u0026lt;ffffffff826018a9\u0026gt;] really_probe+0x159/0x500 drivers/base/dd.c:576(CVE-2021-47344)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/sched: Avoid data corruptions\r\n\r\nWait for all dependencies of a job  to complete before\nkilling it to avoid data corruptions.(CVE-2021-47354)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: macb: fix use after free on rmmod\r\n\r\nplat_dev-\u0026gt;dev-\u0026gt;platform_data is released by platform_device_unregister(),\nuse of pclk and hclk is a use-after-free. Since device unregister won\u0026apos;t\nneed a clk device we adjust the function call sequence to fix this issue.\r\n\r\n[   31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci]\n[   31.275563] Freed by task 306:\n[   30.276782]  platform_device_release+0x25/0x80(CVE-2021-47372)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: acpi: fix resource leak in reconfiguration device addition\r\n\r\nacpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a\nreference on the adapter which is never released which will result in a\nreference count leak and render the adapter unremovable.  Make sure to\nput the adapter after creating the client in the same manner that we do\nfor OF.\r\n\r\n[wsa: fixed title](CVE-2021-47425)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: encx24j600: check error in devm_regmap_init_encx24j600\r\n\r\ndevm_regmap_init may return error which caused by like out of memory,\nthis will results in null pointer dereference later when reading\nor writing register:\r\n\r\ngeneral protection fault in encx24j600_spi_probe\nKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]\nCPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540\nCode: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00\nRSP: 0018:ffffc900010476b8 EFLAGS: 00010207\nRAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000\nRDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094\nRBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a\nR10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001\nR13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08\nFS:  00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459\n spi_probe drivers/spi/spi.c:397\n really_probe drivers/base/dd.c:517\n __driver_probe_device drivers/base/dd.c:751\n driver_probe_device drivers/base/dd.c:782\n __device_attach_driver drivers/base/dd.c:899\n bus_for_each_drv drivers/base/bus.c:427\n __device_attach drivers/base/dd.c:971\n bus_probe_device drivers/base/bus.c:487\n device_add drivers/base/core.c:3364\n __spi_add_device drivers/spi/spi.c:599\n spi_add_device drivers/spi/spi.c:641\n spi_new_device drivers/spi/spi.c:717\n new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e]\n dev_attr_store drivers/base/core.c:2074\n sysfs_kf_write fs/sysfs/file.c:139\n kernfs_fop_write_iter fs/kernfs/file.c:300\n new_sync_write fs/read_write.c:508 (discriminator 4)\n vfs_write fs/read_write.c:594\n ksys_write fs/read_write.c:648\n do_syscall_64 arch/x86/entry/common.c:50\n entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113\r\n\r\nAdd error check in devm_regmap_init_encx24j600 to avoid this situation.(CVE-2021-47440)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: peak_pci: peak_pci_remove(): fix UAF\r\n\r\nWhen remove the module peek_pci, referencing \u0026apos;chan\u0026apos; again after\nreleasing \u0026apos;dev\u0026apos; will cause UAF.\r\n\r\nFix this by releasing \u0026apos;dev\u0026apos; later.\r\n\r\nThe following log reveals it:\r\n\r\n[   35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci]\n[   35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537\n[   35.965513 ] Call Trace:\n[   35.965718 ]  dump_stack_lvl+0xa8/0xd1\n[   35.966028 ]  print_address_description+0x87/0x3b0\n[   35.966420 ]  kasan_report+0x172/0x1c0\n[   35.966725 ]  ? peak_pci_remove+0x16f/0x270 [peak_pci]\n[   35.967137 ]  ? trace_irq_enable_rcuidle+0x10/0x170\n[   35.967529 ]  ? peak_pci_remove+0x16f/0x270 [peak_pci]\n[   35.967945 ]  __asan_report_load8_noabort+0x14/0x20\n[   35.968346 ]  peak_pci_remove+0x16f/0x270 [peak_pci]\n[   35.968752 ]  pci_device_remove+0xa9/0x250(CVE-2021-47456)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nisdn: mISDN: Fix sleeping function called from invalid context\r\n\r\nThe driver can call card-\u0026gt;isac.release() function from an atomic\ncontext.\r\n\r\nFix this by calling this function after releasing the lock.\r\n\r\nThe following log reveals it:\r\n\r\n[   44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018\n[   44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe\n[   44.169574 ] INFO: lockdep is turned off.\n[   44.169899 ] irq event stamp: 0\n[   44.170160 ] hardirqs last  enabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[   44.170627 ] hardirqs last disabled at (0): [\u0026lt;ffffffff814209ed\u0026gt;] copy_process+0x132d/0x3e00\n[   44.171240 ] softirqs last  enabled at (0): [\u0026lt;ffffffff81420a1a\u0026gt;] copy_process+0x135a/0x3e00\n[   44.171852 ] softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[   44.172318 ] Preemption disabled at:\n[   44.172320 ] [\u0026lt;ffffffffa009b0a9\u0026gt;] nj_release+0x69/0x500 [netjet]\n[   44.174441 ] Call Trace:\n[   44.174630 ]  dump_stack_lvl+0xa8/0xd1\n[   44.174912 ]  dump_stack+0x15/0x17\n[   44.175166 ]  ___might_sleep+0x3a2/0x510\n[   44.175459 ]  ? nj_release+0x69/0x500 [netjet]\n[   44.175791 ]  __might_sleep+0x82/0xe0\n[   44.176063 ]  ? start_flush_work+0x20/0x7b0\n[   44.176375 ]  start_flush_work+0x33/0x7b0\n[   44.176672 ]  ? trace_irq_enable_rcuidle+0x85/0x170\n[   44.177034 ]  ? kasan_quarantine_put+0xaa/0x1f0\n[   44.177372 ]  ? kasan_quarantine_put+0xaa/0x1f0\n[   44.177711 ]  __flush_work+0x11a/0x1a0\n[   44.177991 ]  ? flush_work+0x20/0x20\n[   44.178257 ]  ? lock_release+0x13c/0x8f0\n[   44.178550 ]  ? __kasan_check_write+0x14/0x20\n[   44.178872 ]  ? do_raw_spin_lock+0x148/0x360\n[   44.179187 ]  ? read_lock_is_recursive+0x20/0x20\n[   44.179530 ]  ? __kasan_check_read+0x11/0x20\n[   44.179846 ]  ? do_raw_spin_unlock+0x55/0x900\n[   44.180168 ]  ? ____kasan_slab_free+0x116/0x140\n[   44.180505 ]  ? _raw_spin_unlock_irqrestore+0x41/0x60\n[   44.180878 ]  ? skb_queue_purge+0x1a3/0x1c0\n[   44.181189 ]  ? kfree+0x13e/0x290\n[   44.181438 ]  flush_work+0x17/0x20\n[   44.181695 ]  mISDN_freedchannel+0xe8/0x100\n[   44.182006 ]  isac_release+0x210/0x260 [mISDNipac]\n[   44.182366 ]  nj_release+0xf6/0x500 [netjet]\n[   44.182685 ]  nj_remove+0x48/0x70 [netjet]\n[   44.182989 ]  pci_device_remove+0xa9/0x250(CVE-2021-47468)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: vmk80xx: fix bulk-buffer overflow\r\n\r\nThe driver is using endpoint-sized buffers but must not assume that the\ntx and rx buffers are of equal size or a malicious device could overflow\nthe slab-allocated receive buffer when doing bulk transfers.(CVE-2021-47474)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: batman-adv: fix error handling\r\n\r\nSyzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was\nin wrong error handling in batadv_mesh_init().\r\n\r\nBefore this patch batadv_mesh_init() was calling batadv_mesh_free() in case\nof any batadv_*_init() calls failure. This approach may work well, when\nthere is some kind of indicator, which can tell which parts of batadv are\ninitialized; but there isn\u0026apos;t any.\r\n\r\nAll written above lead to cleaning up uninitialized fields. Even if we hide\nODEBUG warning by initializing bat_priv-\u0026gt;nc.work, syzbot was able to hit\nGPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]\r\n\r\nTo fix these bugs we can unwind batadv_*_init() calls one by one.\nIt is good approach for 2 reasons: 1) It fixes bugs on error handling\npath 2) It improves the performance, since we won\u0026apos;t call unneeded\nbatadv_*_free() functions.\r\n\r\nSo, this patch makes all batadv_*_init() clean up all allocated memory\nbefore returning with an error to no call correspoing batadv_*_free()\nand open-codes batadv_mesh_free() with proper order to avoid touching\nuninitialized fields.(CVE-2021-47482)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nregmap: Fix possible double-free in regcache_rbtree_exit()\r\n\r\nIn regcache_rbtree_insert_to_block(), when \u0026apos;present\u0026apos; realloc failed,\nthe \u0026apos;blk\u0026apos; which is supposed to assign to \u0026apos;rbnode-\u0026gt;block\u0026apos; will be freed,\nso \u0026apos;rbnode-\u0026gt;block\u0026apos; points a freed memory, in the error handling path of\nregcache_rbtree_init(), \u0026apos;rbnode-\u0026gt;block\u0026apos; will be freed again in\nregcache_rbtree_exit(), KASAN will report double-free as follows:\r\n\r\nBUG: KASAN: double-free or invalid-free in kfree+0xce/0x390\nCall Trace:\n slab_free_freelist_hook+0x10d/0x240\n kfree+0xce/0x390\n regcache_rbtree_exit+0x15d/0x1a0\n regcache_rbtree_init+0x224/0x2c0\n regcache_init+0x88d/0x1310\n __regmap_init+0x3151/0x4a80\n __devm_regmap_init+0x7d/0x100\n madera_spi_probe+0x10f/0x333 [madera_spi]\n spi_probe+0x183/0x210\n really_probe+0x285/0xc30\r\n\r\nTo fix this, moving up the assignment of rbnode-\u0026gt;block to immediately after\nthe reallocation has succeeded so that the data structure stays valid even\nif the second reallocation fails.(CVE-2021-47483)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields\r\n\r\nOverflowing either addrlimit or bytes_togo can allow userspace to trigger\na buffer overflow of kernel memory. Check for overflows in all the places\ndoing math on user controlled buffers.(CVE-2021-47485)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/tls: Fix flipped sign in tls_err_abort() calls\r\n\r\nsk-\u0026gt;sk_err appears to expect a positive value, a convention that ktls\ndoesn\u0026apos;t always follow and that leads to memory corruption in other code.\nFor instance,\r\n\r\n    [kworker]\n    tls_encrypt_done(..., err=\u0026lt;negative error from crypto request\u0026gt;)\n      tls_err_abort(.., err)\n        sk-\u0026gt;sk_err = err;\r\n\r\n    [task]\n    splice_from_pipe_feed\n      ...\n        tls_sw_do_sendpage\n          if (sk-\u0026gt;sk_err) {\n            ret = -sk-\u0026gt;sk_err;  // ret is positive\r\n\r\n    splice_from_pipe_feed (continued)\n      ret = actor(...)  // ret is still positive and interpreted as bytes\n                        // written, resulting in underflow of buf-\u0026gt;len and\n                        // sd-\u0026gt;len, leading to huge buf-\u0026gt;offset and bogus\n                        // addresses computed in later calls to actor()\r\n\r\nFix all tls_err_abort() callers to pass a negative error code\nconsistently and centralize the error-prone sign flip there, throwing in\na warning to catch future misuse and uninlining the function so it\nreally does only warn once.(CVE-2021-47496)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: pcm: oss: Limit the period size to 16MB\r\n\r\nSet the practical limit to the period size (the fragment shift in OSS)\ninstead of a full 31bit; a too large value could lead to the exhaust\nof memory as we allocate temporary buffers of the period size, too.\r\n\r\nAs of this patch, we set to 16MB limit, which should cover all use\ncases.(CVE-2021-47509)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfp: Fix memory leak in nfp_cpp_area_cache_add()\r\n\r\nIn line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a\nCPP area structure. But in line 807 (#2), when the cache is allocated\nfailed, this CPP area structure is not freed, which will result in\nmemory leak.\r\n\r\nWe can fix it by freeing the CPP area when the cache is allocated\nfailed (#2).\r\n\r\n792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size)\n793 {\n794 \tstruct nfp_cpp_area_cache *cache;\n795 \tstruct nfp_cpp_area *area;\r\n\r\n800\tarea = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0),\n801 \t\t\t\t  0, size);\n\t// #1: allocates and initializes\r\n\r\n802 \tif (!area)\n803 \t\treturn -ENOMEM;\r\n\r\n805 \tcache = kzalloc(sizeof(*cache), GFP_KERNEL);\n806 \tif (!cache)\n807 \t\treturn -ENOMEM; // #2: missing free\r\n\r\n817\treturn 0;\n818 }(CVE-2021-47516)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()\r\n\r\nThe free_rtllib() function frees the \u0026quot;dev\u0026quot; pointer so there is use\nafter free on the next line.  Re-arrange things to avoid that.(CVE-2021-47571)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs\r\n\r\nIn brcmstb_pm_probe(), there are two kinds of leak bugs:\r\n\r\n(1) we need to add of_node_put() when for_each__matching_node() breaks\n(2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_spi: fix error handling in mmc_spi_probe()\r\n\r\nIf mmc_add_host() fails, it doesn\u0026apos;t need to call mmc_remove_host(),\nor it will cause null-ptr-deref, because of deleting a not added\ndevice in mmc_remove_host().\r\n\r\nTo fix this, goto label \u0026apos;fail_glue_init\u0026apos;, if mmc_add_host() fails,\nand change the label \u0026apos;fail_add_host\u0026apos; to \u0026apos;fail_gpiod_request\u0026apos;.(CVE-2023-52708)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: USB: Fix wrong-direction WARNING in plusb.c\r\n\r\nThe syzbot fuzzer detected a bug in the plusb network driver: A\nzero-length control-OUT transfer was treated as a read instead of a\nwrite.  In modern kernels this error provokes a WARNING:\r\n\r\nusb 1-1: BOGUS control dir, pipe 80000280 doesn\u0026apos;t match bRequestType c0\nWARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411\nusb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\nModules linked in:\nCPU: 1 PID: 4645 Comm: dhcpcd Not tainted\n6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google\n01/12/2023\nRIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58\n usb_internal_control_msg drivers/usb/core/message.c:102 [inline]\n usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153\n __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010\n usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068\n pl_vendor_req drivers/net/usb/plusb.c:60 [inline]\n pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]\n pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85\n usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889\n __dev_open+0x297/0x4d0 net/core/dev.c:1417\n __dev_change_flags+0x587/0x750 net/core/dev.c:8530\n dev_change_flags+0x97/0x170 net/core/dev.c:8602\n devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147\n inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979\n sock_do_ioctl+0xcc/0x230 net/socket.c:1169\n sock_ioctl+0x1f8/0x680 net/socket.c:1286\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nThe fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and\nremove the USB_DIR_IN flag.(CVE-2023-52742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/hfi1: Restore allocated resources on failed copyout\r\n\r\nFix a resource leak if an error occurs.(CVE-2023-52747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: gspca: cpia1: shift-out-of-bounds in set_flicker\r\n\r\nSyzkaller reported the following issue:\nUBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27\nshift exponent 245 is too large for 32-bit type \u0026apos;int\u0026apos;\r\n\r\nWhen the value of the variable \u0026quot;sd-\u0026gt;params.exposure.gain\u0026quot; exceeds the\nnumber of bits in an integer, a shift-out-of-bounds error is reported. It\nis triggered because the variable \u0026quot;currentexp\u0026quot; cannot be left-shifted by\nmore than the number of bits in an integer. In order to avoid invalid\nrange during left-shift, the conditional expression is added.(CVE-2023-52764)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add check for negative db_l2nbperpage\r\n\r\nl2nbperpage is log2(number of blks per page), and the minimum legal\nvalue should be 0, not negative.\r\n\r\nIn the case of l2nbperpage being negative, an error will occur\nwhen subsequently used as shift exponent.\r\n\r\nSyzbot reported this bug:\r\n\r\nUBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12\nshift exponent -16777216 is negative(CVE-2023-52810)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlocking/ww_mutex/test: Fix potential workqueue corruption\r\n\r\nIn some cases running with the test-ww_mutex code, I was seeing\nodd behavior where sometimes it seemed flush_workqueue was\nreturning before all the work threads were finished.\r\n\r\nOften this would cause strange crashes as the mutexes would be\nfreed while they were being used.\r\n\r\nLooking at the code, there is a lifetime problem as the\ncontrolling thread that spawns the work allocates the\n\u0026quot;struct stress\u0026quot; structures that are passed to the workqueue\nthreads. Then when the workqueue threads are finished,\nthey free the stress struct that was passed to them.\r\n\r\nUnfortunately the workqueue work_struct node is in the stress\nstruct. Which means the work_struct is freed before the work\nthread returns and while flush_workqueue is waiting.\r\n\r\nIt seems like a better idea to have the controlling thread\nboth allocate and free the stress structures, so that we can\nbe sure we don\u0026apos;t corrupt the workqueue by freeing the structure\nprematurely.\r\n\r\nSo this patch reworks the test to do so, and with this change\nI no longer see the early flush_workqueue returns.(CVE-2023-52836)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: verify mac len before reading mac header\r\n\r\nLLC reads the mac header with eth_hdr without verifying that the skb\nhas an Ethernet header.\r\n\r\nSyzbot was able to enter llc_rcv on a tun device. Tun can insert\npackets without mac len and with user configurable skb-\u0026gt;protocol\n(passing a tun_pi header when not configuring IFF_NO_PI).\r\n\r\n    BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n    BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n    llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n    llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n    llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218\n    __netif_receive_skb_one_core net/core/dev.c:5523 [inline]\n    __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637\n    netif_receive_skb_internal net/core/dev.c:5723 [inline]\n    netif_receive_skb+0x58/0x660 net/core/dev.c:5782\n    tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n    tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002\r\n\r\nAdd a mac_len test before all three eth_hdr(skb) calls under net/llc.\r\n\r\nThere are further uses in include/net/llc_pdu.h. All these are\nprotected by a test skb-\u0026gt;protocol == ETH_P_802_2. Which does not\nprotect against this tun scenario.\r\n\r\nBut the mac_len test added in this patch in llc_fixup_skb will\nindirectly protect those too. That is called from llc_rcv before any\nother LLC code.\r\n\r\nIt is tempting to just add a blanket mac_len check in llc_rcv, but\nnot sure whether that could break valid LLC paths that do not assume\nan Ethernet header. 802.2 LLC may be used on top of non-802.3\nprotocols in principle. The below referenced commit shows that used\nto, on top of Token Ring.\r\n\r\nAt least one of the three eth_hdr uses goes back to before the start\nof git history. But the one that syzbot exercises is introduced in\nthis commit. That commit is old enough (2008), that effectively all\nstable kernels should receive this.(CVE-2023-52843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52875)\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\nnet/mlx5e: Prevent deadlock while disabling aRFS\r\n\r\nWhen disabling aRFS under the `priv-\u0026gt;state_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\r\n\r\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker\u0026apos;s responsibility since\ndisabling aRFS deletes the rules.\r\n\r\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\r\n\r\nKernel log:\r\n\r\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G          I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\r\n\r\nbut task is already holding lock:\nffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nwhich lock already depends on the new lock.\r\n\r\nthe existing dependency chain (in reverse order) is:\r\n\r\n-\u0026gt; #1 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}:\n       __mutex_lock+0x80/0xc90\n       arfs_handle_work+0x4b/0x3b0 [mlx5_core]\n       process_one_work+0x1dc/0x4a0\n       worker_thread+0x1bf/0x3c0\n       kthread+0xd7/0x100\n       ret_from_fork+0x2d/0x50\n       ret_from_fork_asm+0x11/0x20\r\n\r\n-\u0026gt; #0 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}:\n       __lock_acquire+0x17b4/0x2c80\n       lock_acquire+0xd0/0x2b0\n       __flush_work+0x7a/0x4e0\n       __cancel_work_timer+0x131/0x1c0\n       arfs_del_rules+0x143/0x1e0 [mlx5_core]\n       mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n       mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n       ethnl_set_channels+0x28f/0x3b0\n       ethnl_default_set_doit+0xec/0x240\n       genl_family_rcv_msg_doit+0xd0/0x120\n       genl_rcv_msg+0x188/0x2c0\n       netlink_rcv_skb+0x54/0x100\n       genl_rcv+0x24/0x40\n       netlink_unicast+0x1a1/0x270\n       netlink_sendmsg+0x214/0x460\n       __sock_sendmsg+0x38/0x60\n       __sys_sendto+0x113/0x170\n       __x64_sys_sendto+0x20/0x30\n       do_syscall_64+0x40/0xe0\n       entry_SYSCALL_64_after_hwframe+0x46/0x4e\r\n\r\nother info that might help us debug this:\r\n\r\n Possible unsafe locking scenario:\r\n\r\n       CPU0                    CPU1\n       ----                    ----\n  lock(\u0026amp;priv-\u0026gt;state_lock);\n                               lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\n                               lock(\u0026amp;priv-\u0026gt;state_lock);\n  lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\r\n\r\n *** DEADLOCK ***\r\n\r\n3 locks held by ethtool/386089:\n #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n #2: ffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G          I        6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x60/0xa0\n check_noncircular+0x144/0x160\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n ? __flush_work+0x74/0x4e0\n ? save_trace+0x3e/0x360\n ? __flush_work+0x74/0x4e0\n __flush_work+0x7a/0x4e0\n ? __flush_work+0x74/0x4e0\n ? __lock_acquire+0xa78/0x2c80\n ? lock_acquire+0xd0/0x2b0\n ? mark_held_locks+0x49/0x70\n __cancel_work_timer+0x131/0x1c0\n ? mark_held_locks+0x49/0x70\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n ? ethn\n---truncated---(CVE-2024-27014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\r\n\r\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet/pep: fix racy skb_queue_empty() use\r\n\r\nThe receive queues are protected by their respective spin-lock, not\nthe socket lock. This could lead to skb_peek() unexpectedly\nreturning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Use raw spinlock for cgr_lock\r\n\r\nsmp_call_function always runs its callback in hard IRQ context, even on\nPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock\nfor cgr_lock to ensure we aren\u0026apos;t waiting on a sleeping task.\r\n\r\nAlthough this bug has existed for a while, it was not apparent until\ncommit ef2a8d5478b9 (\u0026quot;net: dpaa: Adjust queue depth on rate change\u0026quot;)\nwhich invokes smp_call_function_single via qman_update_cgr_safe every\ntime a link goes up or down.(CVE-2024-35819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: Set page uptodate in the correct place\r\n\r\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we\u0026apos;ve overwritten it with the data it\u0026apos;s supposed to have\nin it will allow a simultaneous reader to see old data.  Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page.(CVE-2024-35821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()\r\n\r\nIn the for statement of lbs_allocate_cmd_buffer(), if the allocation of\ncmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to\nbe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: properly terminate timers for kernel sockets\r\n\r\nWe had various syzbot reports about tcp timers firing after\nthe corresponding netns has been dismantled.\r\n\r\nFortunately Josef Bacik could trigger the issue more often,\nand could test a patch I wrote two years ago.\r\n\r\nWhen TCP sockets are closed, we call inet_csk_clear_xmit_timers()\nto \u0026apos;stop\u0026apos; the timers.\r\n\r\ninet_csk_clear_xmit_timers() can be called from any context,\nincluding when socket lock is held.\nThis is the reason it uses sk_stop_timer(), aka del_timer().\nThis means that ongoing timers might finish much later.\r\n\r\nFor user sockets, this is fine because each running timer\nholds a reference on the socket, and the user socket holds\na reference on the netns.\r\n\r\nFor kernel sockets, we risk that the netns is freed before\ntimer can complete, because kernel sockets do not hold\nreference on the netns.\r\n\r\nThis patch adds inet_csk_clear_xmit_timers_sync() function\nthat using sk_stop_timer_sync() to make sure all timers\nare terminated before the kernel socket is released.\nModules using kernel sockets close them in their netns exit()\nhandler.\r\n\r\nAlso add sock_not_owned_by_me() helper to get LOCKDEP\nsupport : inet_csk_clear_xmit_timers_sync() must not be called\nwhile socket lock is held.\r\n\r\nIt is very possible we can revert in the future commit\n3a58f13a881e (\u0026quot;net: rds: acquire refcount on TCP sockets\u0026quot;)\nwhich attempted to solve the issue in rds only.\n(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)\r\n\r\nWe probably can remove the check_net() tests from\ntcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: send: handle path ref underflow in header iterate_inode_ref()\r\n\r\nChange BUG_ON to proper error handling if building the path buffer\nfails. The pointers are not printed so we don\u0026apos;t accidentally leak kernel\naddresses.(CVE-2024-35935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: check A-MSDU format more carefully\r\n\r\nIf it looks like there\u0026apos;s another subframe in the A-MSDU\nbut the header isn\u0026apos;t fully there, we can end up reading\ndata out of bounds, only to discard later. Make this a\nbit more careful and check if the subframe header can\neven be present.(CVE-2024-35937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndyndbg: fix old BUG_ON in \u0026gt;control parser\r\n\r\nFix a BUG_ON from 2009.  Even if it looks \u0026quot;unreachable\u0026quot; (I didn\u0026apos;t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead.(CVE-2024-35947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: Avoid infinite loop trying to resize local TT\r\n\r\nIf the MTU of one of an attached interface becomes too small to transmit\nthe local translation table then it must be resized to fit inside all\nfragments (when enabled) or a single packet.\r\n\r\nBut if the MTU becomes too low to transmit even the header + the VLAN\nspecific part then the resizing of the local TT will never succeed. This\ncan for example happen when the usable space is 110 bytes and 11 VLANs are\non top of batman-adv. In this case, at least 116 byte would be needed.\nThere will just be an endless spam of\r\n\r\n   batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)\r\n\r\nin the log but the function will never finish. Problem here is that the\ntimeout will be halved all the time and will then stagnate at 0 and\ntherefore never be able to reduce the table even more.\r\n\r\nThere are other scenarios possible with a similar result. The number of\nBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too\nhigh to fit inside a packet. Such a scenario can therefore happen also with\nonly a single VLAN + 7 non-purgable addresses - requiring at least 120\nbytes.\r\n\r\nWhile this should be handled proactively when:\r\n\r\n* interface with too low MTU is added\n* VLAN is added\n* non-purgeable local mac is added\n* MTU of an attached interface is reduced\n* fragmentation setting gets disabled (which most likely requires dropping\n  attached interfaces)\r\n\r\nnot all of these scenarios can be prevented because batman-adv is only\nconsuming events without the the possibility to prevent these actions\n(non-purgable MAC address added, MTU of an attached interface is reduced).\nIt is therefore necessary to also make sure that the code is able to handle\nalso the situations when there were already incompatible system\nconfiguration are present.(CVE-2024-35982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: fix possible out-of-bounds in gsm0_receive()\r\n\r\nAssuming the following:\n- side A configures the n_gsm in basic option mode\n- side B sends the header of a basic option mode frame with data length 1\n- side A switches to advanced option mode\n- side B sends 2 data bytes which exceeds gsm-\u0026gt;len\n  Reason: gsm-\u0026gt;len is not used in advanced option mode.\n- side A switches to basic option mode\n- side B keeps sending until gsm0_receive() writes past gsm-\u0026gt;buf\n  Reason: Neither gsm-\u0026gt;state nor gsm-\u0026gt;len have been reset after\n  reconfiguration.\r\n\r\nFix this by changing gsm-\u0026gt;count to gsm-\u0026gt;len comparison from equal to less\nthan. Also add upper limit checks against the constant MAX_MRU in\ngsm0_receive() and gsm1_receive() to harden against memory corruption of\ngsm-\u0026gt;len and gsm-\u0026gt;mru.\r\n\r\nAll other checks remain as we still need to limit the data according to the\nuser configuration and actual payload size.(CVE-2024-36016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix UAF in error path\r\n\r\nSam Page (sam4k) working with Trend Micro Zero Day Initiative reported\na UAF in the tipc_buf_append() error path:\r\n\r\nBUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0\nlinux/net/core/skbuff.c:1183\nRead of size 8 at addr ffff88804d2a7c80 by task poc/8034\r\n\r\nCPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.0-debian-1.16.0-5 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack linux/lib/dump_stack.c:88\n dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106\n print_address_description linux/mm/kasan/report.c:377\n print_report+0xc4/0x620 linux/mm/kasan/report.c:488\n kasan_report+0xda/0x110 linux/mm/kasan/report.c:601\n kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183\n skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026\n skb_release_all linux/net/core/skbuff.c:1094\n __kfree_skb linux/net/core/skbuff.c:1108\n kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144\n kfree_skb linux/./include/linux/skbuff.h:1244\n tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186\n tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324\n tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824\n tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159\n tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390\n udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108\n udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186\n udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346\n __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422\n ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254\n dst_input linux/./include/net/dst.h:461\n ip_rcv_finish linux/net/ipv4/ip_input.c:449\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534\n __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648\n process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976\n __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576\n napi_poll linux/net/core/dev.c:6645\n net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781\n __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553\n do_softirq linux/kernel/softirq.c:454\n do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381\n local_bh_enable linux/./include/linux/bottom_half.h:33\n rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851\n __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378\n dev_queue_xmit linux/./include/linux/netdevice.h:3169\n neigh_hh_output linux/./include/net/neighbour.h:526\n neigh_output linux/./include/net/neighbour.h:540\n ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235\n __ip_finish_output linux/net/ipv4/ip_output.c:313\n __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295\n ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323\n NF_HOOK_COND linux/./include/linux/netfilter.h:303\n ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433\n dst_output linux/./include/net/dst.h:451\n ip_local_out linux/net/ipv4/ip_output.c:129\n ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492\n udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963\n udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250\n inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850\n sock_sendmsg_nosec linux/net/socket.c:730\n __sock_sendmsg linux/net/socket.c:745\n __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191\n __do_sys_sendto linux/net/socket.c:2203\n __se_sys_sendto linux/net/socket.c:2199\n __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199\n do_syscall_x64 linux/arch/x86/entry/common.c:52\n do_syscall_\n---truncated---(CVE-2024-36886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent NULL dereference in ip6_output()\r\n\r\nAccording to syzbot, there is a chance that ip6_dst_idev()\nreturns NULL in ip6_output(). Most places in IPv6 stack\ndeal with a NULL idev just fine, but not here.\r\n\r\nsyzbot reported:\r\n\r\ngeneral protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]\nCPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237\nCode: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff\nRSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000\nRDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48\nRBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad\nR10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0\nR13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000\nFS:  00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358\n  sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248\n  sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653\n  sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783\n  sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]\n  sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212\n  sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n  sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169\n  sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73\n  __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234\n  sctp_connect net/sctp/socket.c:4819 [inline]\n  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n  __sys_connect_file net/socket.c:2048 [inline]\n  __sys_connect+0x2df/0x310 net/socket.c:2065\n  __do_sys_connect net/socket.c:2075 [inline]\n  __se_sys_connect net/socket.c:2072 [inline]\n  __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets\r\n\r\nTCP_SYN_RECV state is really special, it is only used by\ncross-syn connections, mostly used by fuzzers.\r\n\r\nIn the following crash [1], syzbot managed to trigger a divide\nby zero in tcp_rcv_space_adjust()\r\n\r\nA socket makes the following state transitions,\nwithout ever calling tcp_init_transfer(),\nmeaning tcp_init_buffer_space() is also not called.\r\n\r\n         TCP_CLOSE\nconnect()\n         TCP_SYN_SENT\n         TCP_SYN_RECV\nshutdown() -\u0026gt; tcp_shutdown(sk, SEND_SHUTDOWN)\n         TCP_FIN_WAIT1\r\n\r\nTo fix this issue, change tcp_shutdown() to not\nperform a TCP_SYN_RECV -\u0026gt; TCP_FIN_WAIT1 transition,\nwhich makes no sense anyway.\r\n\r\nWhen tcp_rcv_state_process() later changes socket state\nfrom TCP_SYN_RECV to TCP_ESTABLISH, then look at\nsk-\u0026gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,\nand send a FIN packet from a sane socket state.\r\n\r\nThis means tcp_send_fin() can now be called from BH\ncontext, and must use GFP_ATOMIC allocations.\r\n\r\n[1]\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767\nCode: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 \u0026lt;48\u0026gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48\nRSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246\nRAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7\nR10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30\nR13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da\nFS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513\n  tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578\n  inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680\n  sock_recvmsg_nosec net/socket.c:1046 [inline]\n  sock_recvmsg+0x109/0x280 net/socket.c:1068\n  ____sys_recvmsg+0x1db/0x470 net/socket.c:2803\n  ___sys_recvmsg net/socket.c:2845 [inline]\n  do_recvmmsg+0x474/0xae0 net/socket.c:2939\n  __sys_recvmmsg net/socket.c:3018 [inline]\n  __do_sys_recvmmsg net/socket.c:3041 [inline]\n  __se_sys_recvmmsg net/socket.c:3034 [inline]\n  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7faeb6363db9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9\nRDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c\nR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\r\n\r\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won\u0026apos;t be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\r\n\r\nThis will suppress following BUG_ON():\r\n\r\n[  449.843143] ------------[ cut here ]------------\n[  449.848302] kernel BUG at mm/vmalloc.c:2727!\n[  449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[  449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[  449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[  449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[  449.882910] RIP: 0010:vunmap+0x2e/0x30\n[  449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 \u0026lt;0f\u0026gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[  449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[  449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[  449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[  449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[  449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[  449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[  449.953701] FS:  0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[  449.962732] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[  449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  449.993028] Call Trace:\n[  449.995756]  __iommu_dma_free+0x96/0x100\n[  450.000139]  bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[  450.006171]  bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[  450.011910]  bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[  450.018136]  fc_rport_work+0x103/0x5b0 [libfc]\n[  450.023103]  process_one_work+0x1e8/0x3c0\n[  450.027581]  worker_thread+0x50/0x3b0\n[  450.031669]  ? rescuer_thread+0x370/0x370\n[  450.036143]  kthread+0x149/0x170\n[  450.039744]  ? set_kthread_struct+0x40/0x40\n[  450.044411]  ret_from_fork+0x22/0x30\n[  450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[  450.048497]  libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[  450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul\ninstead of memdup_user.(CVE-2024-36934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Move NPIV\u0026apos;s transport unregistration to after resource clean up\r\n\r\nThere are cases after NPIV deletion where the fabric switch still believes\nthe NPIV is logged into the fabric.  This occurs when a vport is\nunregistered before the Remove All DA_ID CT and LOGO ELS are sent to the\nfabric.\r\n\r\nCurrently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including\nthe fabric D_ID, removes the last ndlp reference and frees the ndlp rport\nobject.  This sometimes causes the race condition where the final DA_ID and\nLOGO are skipped from being sent to the fabric switch.\r\n\r\nFix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID\nand LOGO are sent.(CVE-2024-36952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix invalid reads in fence signaled events\r\n\r\nCorrectly set the length of the drm_event to the size of the structure\nthat\u0026apos;s actually used.\r\n\r\nThe length of the drm_event was set to the parent structure instead of\nto the drm_vmw_event_fence which is supposed to be read. drm_read\nuses the length parameter to copy the event to the user space thus\nresuling in oob reads.(CVE-2024-36960)",
  "id": "OESA-2024-1736",
  "modified": "2026-08-06T11:07:12Z",
  "published": "2024-06-21T11:07:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1736"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47229"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47234"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47249"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47257"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47267"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47281"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47310"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47321"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47334"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47344"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47354"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47372"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47425"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47440"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47456"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47468"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47474"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47482"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47483"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47485"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47496"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47509"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47516"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47571"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48693"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52708"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52764"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52810"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52836"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52843"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52875"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52880"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27402"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35819"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35910"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35935"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35937"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36886"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36901"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36905"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36919"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36960"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47229",
    "CVE-2021-47234",
    "CVE-2021-47249",
    "CVE-2021-47257",
    "CVE-2021-47267",
    "CVE-2021-47281",
    "CVE-2021-47301",
    "CVE-2021-47310",
    "CVE-2021-47321",
    "CVE-2021-47334",
    "CVE-2021-47344",
    "CVE-2021-47354",
    "CVE-2021-47372",
    "CVE-2021-47425",
    "CVE-2021-47440",
    "CVE-2021-47456",
    "CVE-2021-47468",
    "CVE-2021-47474",
    "CVE-2021-47482",
    "CVE-2021-47483",
    "CVE-2021-47485",
    "CVE-2021-47496",
    "CVE-2021-47509",
    "CVE-2021-47516",
    "CVE-2021-47571",
    "CVE-2022-48693",
    "CVE-2023-52708",
    "CVE-2023-52742",
    "CVE-2023-52747",
    "CVE-2023-52764",
    "CVE-2023-52810",
    "CVE-2023-52836",
    "CVE-2023-52843",
    "CVE-2023-52875",
    "CVE-2023-52880",
    "CVE-2024-27014",
    "CVE-2024-27019",
    "CVE-2024-27402",
    "CVE-2024-35819",
    "CVE-2024-35821",
    "CVE-2024-35828",
    "CVE-2024-35910",
    "CVE-2024-35935",
    "CVE-2024-35937",
    "CVE-2024-35947",
    "CVE-2024-35982",
    "CVE-2024-36016",
    "CVE-2024-36886",
    "CVE-2024-36901",
    "CVE-2024-36905",
    "CVE-2024-36919",
    "CVE-2024-36934",
    "CVE-2024-36952",
    "CVE-2024-36960"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-tools-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "kernel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-209.0.0.117.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-tools-devel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "kernel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-209.0.0.117.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\r\n\r\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\nLinux\u0026apos;s afs client switches between them when talking to a non-YFS server\nif the read size, the file position or the sum of the two have the upper 32\nbits set of the 64-bit value.\r\n\r\nThis is a problem, however, since the file position and length fields of\nFS.FetchData are *signed* 32-bit values.\r\n\r\nFix this by capturing the capability bits obtained from the fileserver when\nit\u0026apos;s sent an FS.GetCapabilities RPC, rather than just discarding them, and\nthen picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\nswitch on the parameter values.\r\n\r\nThis capabilities flag could also be used to limit the maximum size of the\nfile, but all servers must be checked for that.\r\n\r\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\n32-bit values.  It\u0026apos;s also not a problem with Auristor servers as its\nYFS.FetchData64 op uses unsigned 64-bit values.\r\n\r\nThis can be tested by cloning a git repo through an OpenAFS client to an\nOpenAFS server and then doing \u0026quot;git status\u0026quot; on it from a Linux afs\nclient[1].  Provided the clone has a pack file that\u0026apos;s in the 2G-4G range,\nthe git status will show errors like:\r\n\r\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\r\n\r\nThis can be observed in the server\u0026apos;s FileLog with something like the\nfollowing appearing:\r\n\r\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\n...\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\r\n\r\nNote the file position of 18446744071815340032.  This is the requested file\nposition sign-extended.(CVE-2021-47366)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Fix possible access to freed memory in link clear\r\n\r\nAfter modifying the QP to the Error state, all RX WR would be completed\nwith WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not\nwait for it is done, but destroy the QP and free the link group directly.\nSo there is a risk that accessing the freed memory in tasklet context.\r\n\r\nHere is a crash example:\r\n\r\n BUG: unable to handle page fault for address: ffffffff8f220860\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060\n Oops: 0002 [#1] SMP PTI\n CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE     5.10.0-0607+ #23\n Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018\n RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0\n Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e \u0026lt;48\u0026gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32\n RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086\n RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000\n RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00\n RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b\n R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010\n R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040\n FS:  0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  _raw_spin_lock_irqsave+0x30/0x40\n  mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]\n  smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]\n  tasklet_action_common.isra.21+0x66/0x100\n  __do_softirq+0xd5/0x29c\n  asm_call_irq_on_stack+0x12/0x20\n  \u0026lt;/IRQ\u0026gt;\n  do_softirq_own_stack+0x37/0x40\n  irq_exit_rcu+0x9d/0xa0\n  sysvec_call_function_single+0x34/0x80\n  asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/srp: Set scmnd-\u0026gt;result only when scmnd is not NULL\r\n\r\nThis change fixes the following kernel NULL pointer dereference\nwhich is reproduced by blktests srp/007 occasionally.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000170\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014\nWorkqueue:  0x0 (kblockd)\nRIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]\nCode: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 \u0026lt;41\u0026gt; 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9\nRSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282\nRAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000\nRDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff\nRBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001\nR10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000\nR13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000\nFS:  0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __ib_process_cq+0xb7/0x280 [ib_core]\n ib_poll_handler+0x2b/0x130 [ib_core]\n irq_poll_softirq+0x93/0x150\n __do_softirq+0xee/0x4b8\n irq_exit_rcu+0xf7/0x130\n sysvec_apic_timer_interrupt+0x8e/0xc0\n \u0026lt;/IRQ\u0026gt;(CVE-2022-48692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrpmsg: virtio: Free driver_override when rpmsg_remove()\r\n\r\nFree driver_override when rpmsg_remove(), otherwise\nthe following memory leak will occur:\r\n\r\nunreferenced object 0xffff0000d55d7080 (size 128):\n  comm \u0026quot;kworker/u8:2\u0026quot;, pid 56, jiffies 4294893188 (age 214.272s)\n  hex dump (first 32 bytes):\n    72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00  rpmsg_ns........\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;000000009c94c9c1\u0026gt;] __kmem_cache_alloc_node+0x1f8/0x320\n    [\u0026lt;000000002300d89b\u0026gt;] __kmalloc_node_track_caller+0x44/0x70\n    [\u0026lt;00000000228a60c3\u0026gt;] kstrndup+0x4c/0x90\n    [\u0026lt;0000000077158695\u0026gt;] driver_set_override+0xd0/0x164\n    [\u0026lt;000000003e9c4ea5\u0026gt;] rpmsg_register_device_override+0x98/0x170\n    [\u0026lt;000000001c0c89a8\u0026gt;] rpmsg_ns_register_device+0x24/0x30\n    [\u0026lt;000000008bbf8fa2\u0026gt;] rpmsg_probe+0x2e0/0x3ec\n    [\u0026lt;00000000e65a68df\u0026gt;] virtio_dev_probe+0x1c0/0x280\n    [\u0026lt;00000000443331cc\u0026gt;] really_probe+0xbc/0x2dc\n    [\u0026lt;00000000391064b1\u0026gt;] __driver_probe_device+0x78/0xe0\n    [\u0026lt;00000000a41c9a5b\u0026gt;] driver_probe_device+0xd8/0x160\n    [\u0026lt;000000009c3bd5df\u0026gt;] __device_attach_driver+0xb8/0x140\n    [\u0026lt;0000000043cd7614\u0026gt;] bus_for_each_drv+0x7c/0xd4\n    [\u0026lt;000000003b929a36\u0026gt;] __device_attach+0x9c/0x19c\n    [\u0026lt;00000000a94e0ba8\u0026gt;] device_initial_probe+0x14/0x20\n    [\u0026lt;000000003c999637\u0026gt;] bus_probe_device+0xa0/0xac(CVE-2023-52670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: avoid format-overflow warning\r\n\r\nWith gcc and W=1 option, there\u0026apos;s a warning like this:\r\n\r\nfs/f2fs/compress.c: In function \u2018f2fs_init_page_array_cache\u2019:\nfs/f2fs/compress.c:1984:47: error: \u2018%u\u2019 directive writing between\n1 and 7 bytes into a region of size between 5 and 8\n[-Werror=format-overflow=]\n 1984 |  sprintf(slab_name, \u0026quot;f2fs_page_array_entry-%u:%u\u0026quot;, MAJOR(dev),\n\t\tMINOR(dev));\n      |                                               ^~\r\n\r\nString \u0026quot;f2fs_page_array_entry-%u:%u\u0026quot; can up to 35. The first \u0026quot;%u\u0026quot; can up\nto 4 and the second \u0026quot;%u\u0026quot; can up to 7, so total size is \u0026quot;24 + 4 + 7 = 35\u0026quot;.\nslab_name\u0026apos;s size should be 35 rather than 32.(CVE-2023-52748)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: core: Run atomic i2c xfer when !preemptible\r\n\r\nSince bae1d3a05a8b, i2c transfers are non-atomic if preemption is\ndisabled. However, non-atomic i2c transfers require preemption (e.g. in\nwait_for_completion() while waiting for the DMA).\r\n\r\npanic() calls preempt_disable_notrace() before calling\nemergency_restart(). Therefore, if an i2c device is used for the\nrestart, the xfer should be atomic. This avoids warnings like:\r\n\r\n[   12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0\n[   12.676926] Voluntary context switch within RCU read-side critical section!\n...\n[   12.742376]  schedule_timeout from wait_for_completion_timeout+0x90/0x114\n[   12.749179]  wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70\n...\n[   12.994527]  atomic_notifier_call_chain from machine_restart+0x34/0x58\n[   13.001050]  machine_restart from panic+0x2a8/0x32c\r\n\r\nUse !preemptible() instead, which is basically the same check as\npre-v5.2.(CVE-2023-52791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: fix a possible null pointer dereference\r\n\r\nIn versatile_panel_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vidtv: mux: Add check and kfree for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.\nMoreover, use kfree() in the later error handling in order to avoid\nmemory leak.(CVE-2023-52841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52873)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change\r\n\r\nWhile PLL CPUX clock rate change when CPU is running from it works in\nvast majority of cases, now and then it causes instability. This leads\nto system crashes and other undefined behaviour. After a lot of testing\n(30+ hours) while also doing a lot of frequency switches, we can\u0026apos;t\nobserve any instability issues anymore when doing reparenting to stable\nclock like 24 MHz oscillator.(CVE-2023-52882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: do not free live element\r\n\r\nPablo reports a crash with large batches of elements with a\nback-to-back add/remove pattern.  Quoting Pablo:\r\n\r\n  add_elem(\u0026quot;00000000\u0026quot;) timeout 100 ms\n  ...\n  add_elem(\u0026quot;0000000X\u0026quot;) timeout 100 ms\n  del_elem(\u0026quot;0000000X\u0026quot;) \u0026lt;---------------- delete one that was just added\n  ...\n  add_elem(\u0026quot;00005000\u0026quot;) timeout 100 ms\r\n\r\n  1) nft_pipapo_remove() removes element 0000000X\n  Then, KASAN shows a splat.\r\n\r\nLooking at the remove function there is a chance that we will drop a\nrule that maps to a non-deactivated element.\r\n\r\nRemoval happens in two steps, first we do a lookup for key k and return the\nto-be-removed element and mark it as inactive in the next generation.\nThen, in a second step, the element gets removed from the set/map.\r\n\r\nThe _remove function does not work correctly if we have more than one\nelement that share the same key.\r\n\r\nThis can happen if we insert an element into a set when the set already\nholds an element with same key, but the element mapping to the existing\nkey has timed out or is not active in the next generation.\r\n\r\nIn such case its possible that removal will unmap the wrong element.\nIf this happens, we will leak the non-deactivated element, it becomes\nunreachable.\r\n\r\nThe element that got deactivated (and will be freed later) will\nremain reachable in the set data structure, this can result in\na crash when such an element is retrieved during lookup (stale\npointer).\r\n\r\nAdd a check that the fully matching key does in fact map to the element\nthat we have marked as inactive in the deactivation step.\nIf not, we need to continue searching.\r\n\r\nAdd a bug/warn trap at the end of the function as well, the remove\nfunction must not ever be called with an invisible/unreachable/non-existent\nelement.\r\n\r\nv2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Fix unremoved procfs host directory regression\r\n\r\nCommit fc663711b944 (\u0026quot;scsi: core: Remove the /proc/scsi/${proc_name}\ndirectory earlier\u0026quot;) fixed a bug related to modules loading/unloading, by\nadding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led\nto a potential duplicate call to the hostdir_rm() routine, since it\u0026apos;s also\ncalled from scsi_host_dev_release(). That triggered a regression report,\nwhich was then fixed by commit be03df3d4bfe (\u0026quot;scsi: core: Fix a procfs host\ndirectory removal regression\u0026quot;). The fix just dropped the hostdir_rm() call\nfrom dev_release().\r\n\r\nBut it happens that this proc directory is created on scsi_host_alloc(),\nand that function \u0026quot;pairs\u0026quot; with scsi_host_dev_release(), while\nscsi_remove_host() pairs with scsi_add_host(). In other words, it seems the\nreason for removing the proc directory on dev_release() was meant to cover\ncases in which a SCSI host structure was allocated, but the call to\nscsi_add_host() didn\u0026apos;t happen. And that pattern happens to exist in some\nerror paths, for example.\r\n\r\nSyzkaller causes that by using USB raw gadget device, error\u0026apos;ing on\nusb-storage driver, at usb_stor_probe2(). By checking that path, we can see\nthat the BadDevice label leads to a scsi_host_put() after a SCSI host\nallocation, but there\u0026apos;s no call to scsi_add_host() in such path. That leads\nto messages like this in dmesg (and a leak of the SCSI host proc\nstructure):\r\n\r\nusb-storage 4-1:87.51: USB Mass Storage device detected\nproc_dir_entry \u0026apos;scsi/usb-storage\u0026apos; already registered\nWARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376\r\n\r\nThe proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),\nbut guard that with the state check for SHOST_CREATED; there is even a\ncomment in scsi_host_dev_release() detailing that: such conditional is\nmeant for cases where the SCSI host was allocated but there was no calls to\n{add,remove}_host(), like the usb-storage case.\r\n\r\nThis is what we propose here and with that, the error path of usb-storage\ndoes not trigger the warning anymore.(CVE-2024-26935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: validate request buffer size in smb2_allocate_rsp_buf()\r\n\r\nThe response buffer should be allocated in smb2_allocate_rsp_buf\nbefore validating request. But the fields in payload as well as smb2 header\nis used in smb2_allocate_rsp_buf(). This patch add simple buffer size\nvalidation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses\r\n\r\nSince commit a4d5613c4dc6 (\u0026quot;arm: extend pfn_valid to take into account\nfreed memory map alignment\u0026quot;) changes the semantics of pfn_valid() to check\npresence of the memory map for a PFN. A valid page for an address which\nis reserved but not mapped by the kernel[1], the system crashed during\nsome uio test with the following memory layout:\r\n\r\n node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]\n node   0: [mem 0x00000000d0000000-0x00000000da1fffff]\n the uio layout is\uff1a0xc0900000, 0x100000\r\n\r\nthe crash backtrace like:\r\n\r\n  Unable to handle kernel paging request at virtual address bff00000\n  [...]\n  CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1\n  Hardware name: Generic DT based system\n  PC is at b15_flush_kern_dcache_area+0x24/0x3c\n  LR is at __sync_icache_dcache+0x6c/0x98\n  [...]\n   (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)\n   (__sync_icache_dcache) from (set_pte_at+0x28/0x54)\n   (set_pte_at) from (remap_pfn_range+0x1a0/0x274)\n   (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])\n   (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)\n   (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)\n   (__do_mmap_mm) from (do_mmap+0x50/0x58)\n   (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)\n   (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)\n   (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)\n  Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)\n  ---[ end trace 09cf0734c3805d52 ]---\n  Kernel panic - not syncing: Fatal exception\r\n\r\nSo check if PG_reserved was set to solve this issue.\r\n\r\n[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/(CVE-2024-26947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\r\n\r\nIf -\u0026gt;NameOffset of smb2_create_req is smaller than Buffer offset of\nsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.\nThis patch set the minimum value of the name offset to the buffer offset\nto validate name length of smb2_create_req().(CVE-2024-26954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: swap: fix race between free_swap_and_cache() and swapoff()\r\n\r\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread.  This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\r\n\r\nThis is a theoretical problem and I haven\u0026apos;t been able to provoke it from a\ntest case.  But there has been agreement based on code review that this is\npossible (see link below).\r\n\r\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff().  There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free.  This isn\u0026apos;t present in get_swap_device()\nbecause it doesn\u0026apos;t make sense in general due to the race between getting\nthe reference and swapoff.  So I\u0026apos;ve added an equivalent check directly in\nfree_swap_and_cache().\r\n\r\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\r\n\r\n--8\u0026lt;-----\r\n\r\n__swap_entry_free() might be the last user and result in\n\u0026quot;count == SWAP_HAS_CACHE\u0026quot;.\r\n\r\nswapoff-\u0026gt;try_to_unuse() will stop as soon as soon as si-\u0026gt;inuse_pages==0.\r\n\r\nSo the question is: could someone reclaim the folio and turn\nsi-\u0026gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().\r\n\r\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\r\n\r\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\r\n\r\nProcess 1 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\r\n\r\nProcess 2 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\r\n\r\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\r\n\r\n__try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt;\nput_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt;\nswap_entry_free()-\u0026gt;swap_range_free()-\u0026gt;\n...\nWRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries);\r\n\r\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\r\n\r\n--8\u0026lt;-----(CVE-2024-26960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Prevent deadlock while disabling aRFS\r\n\r\nWhen disabling aRFS under the `priv-\u0026gt;state_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\r\n\r\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker\u0026apos;s responsibility since\ndisabling aRFS deletes the rules.\r\n\r\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\r\n\r\nKernel log:\r\n\r\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G          I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\r\n\r\nbut task is already holding lock:\nffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nwhich lock already depends on the new lock.\r\n\r\nthe existing dependency chain (in reverse order) is:\r\n\r\n-\u0026gt; #1 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}:\n       __mutex_lock+0x80/0xc90\n       arfs_handle_work+0x4b/0x3b0 [mlx5_core]\n       process_one_work+0x1dc/0x4a0\n       worker_thread+0x1bf/0x3c0\n       kthread+0xd7/0x100\n       ret_from_fork+0x2d/0x50\n       ret_from_fork_asm+0x11/0x20\r\n\r\n-\u0026gt; #0 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}:\n       __lock_acquire+0x17b4/0x2c80\n       lock_acquire+0xd0/0x2b0\n       __flush_work+0x7a/0x4e0\n       __cancel_work_timer+0x131/0x1c0\n       arfs_del_rules+0x143/0x1e0 [mlx5_core]\n       mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n       mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n       ethnl_set_channels+0x28f/0x3b0\n       ethnl_default_set_doit+0xec/0x240\n       genl_family_rcv_msg_doit+0xd0/0x120\n       genl_rcv_msg+0x188/0x2c0\n       netlink_rcv_skb+0x54/0x100\n       genl_rcv+0x24/0x40\n       netlink_unicast+0x1a1/0x270\n       netlink_sendmsg+0x214/0x460\n       __sock_sendmsg+0x38/0x60\n       __sys_sendto+0x113/0x170\n       __x64_sys_sendto+0x20/0x30\n       do_syscall_64+0x40/0xe0\n       entry_SYSCALL_64_after_hwframe+0x46/0x4e\r\n\r\nother info that might help us debug this:\r\n\r\n Possible unsafe locking scenario:\r\n\r\n       CPU0                    CPU1\n       ----                    ----\n  lock(\u0026amp;priv-\u0026gt;state_lock);\n                               lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\n                               lock(\u0026amp;priv-\u0026gt;state_lock);\n  lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\r\n\r\n *** DEADLOCK ***\r\n\r\n3 locks held by ethtool/386089:\n #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n #2: ffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G          I        6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x60/0xa0\n check_noncircular+0x144/0x160\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n ? __flush_work+0x74/0x4e0\n ? save_trace+0x3e/0x360\n ? __flush_work+0x74/0x4e0\n __flush_work+0x7a/0x4e0\n ? __flush_work+0x74/0x4e0\n ? __lock_acquire+0xa78/0x2c80\n ? lock_acquire+0xd0/0x2b0\n ? mark_held_locks+0x49/0x70\n __cancel_work_timer+0x131/0x1c0\n ? mark_held_locks+0x49/0x70\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n ? ethn\n---truncated---(CVE-2024-27014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: walk over current view on netlink dump\r\n\r\nThe generation mask can be updated while netlink dump is in progress.\nThe pipapo set backend walk iterator cannot rely on it to infer what\nview of the datastructure is to be used. Add notation to specify if user\nwants to read/update the set.\r\n\r\nBased on patch from Florian Westphal.(CVE-2024-27017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\r\n\r\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential NULL pointer dereferences in \u0026apos;dcn10_set_output_transfer_func()\u0026apos;\r\n\r\nThe \u0026apos;stream\u0026apos; pointer is used in dcn10_set_output_transfer_func() before\nthe check if \u0026apos;stream\u0026apos; is NULL.\r\n\r\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check \u0026apos;stream\u0026apos; (see line 1875)(CVE-2024-27044)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ll_temac: platform_get_resource replaced by wrong function\r\n\r\nThe function platform_get_resource was replaced with\ndevm_platform_ioremap_resource_byname and is called using 0 as name.\r\n\r\nThis eventually ends up in platform_get_resource_byname in the call\nstack, where it causes a null pointer in strcmp.\r\n\r\n\tif (type == resource_type(r) \u0026amp;\u0026amp; !strcmp(r-\u0026gt;name, name))\r\n\r\nIt should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Use raw spinlock for cgr_lock\r\n\r\nsmp_call_function always runs its callback in hard IRQ context, even on\nPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock\nfor cgr_lock to ensure we aren\u0026apos;t waiting on a sleeping task.\r\n\r\nAlthough this bug has existed for a while, it was not apparent until\ncommit ef2a8d5478b9 (\u0026quot;net: dpaa: Adjust queue depth on rate change\u0026quot;)\nwhich invokes smp_call_function_single via qman_update_cgr_safe every\ntime a link goes up or down.(CVE-2024-35819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: Set page uptodate in the correct place\r\n\r\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we\u0026apos;ve overwritten it with the data it\u0026apos;s supposed to have\nin it will allow a simultaneous reader to see old data.  Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page.(CVE-2024-35821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()\r\n\r\nIn the for statement of lbs_allocate_cmd_buffer(), if the allocation of\ncmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to\nbe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix UAF in smb2_reconnect_server()\r\n\r\nThe UAF bug is due to smb2_reconnect_server() accessing a session that\nis already being teared down by another thread that is executing\n__cifs_put_smb_ses().  This can happen when (a) the client has\nconnection to the server but no session or (b) another thread ends up\nsetting @ses-\u0026gt;ses_status again to something different than\nSES_EXITING.\r\n\r\nTo fix this, we need to make sure to unconditionally set\n@ses-\u0026gt;ses_status to SES_EXITING and prevent any other threads from\nsetting a new status while we\u0026apos;re still tearing it down.\r\n\r\nThe following can be reproduced by adding some delay to right after\nthe ipc is freed in __cifs_put_smb_ses() - which will give\nsmb2_reconnect_server() worker a chance to run and then accessing\n@ses-\u0026gt;ipc:\r\n\r\nkinit ...\nmount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10\n[disconnect srv]\nls /mnt/1 \u0026amp;\u0026gt;/dev/null\nsleep 30\nkdestroy\n[reconnect srv]\nsleep 10\numount /mnt/1\n...\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\ngeneral protection fault, probably for non-canonical address\n0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39\n04/01/2014\nWorkqueue: cifsiod smb2_reconnect_server [cifs]\nRIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0\nCode: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad\nde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 \u0026lt;48\u0026gt; 8b 01 48 39 f8 75\n7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8\nRSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83\nRAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b\nRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800\nRBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000\nR13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000\nFS: 0000000000000000(0000) GS:ffff888157c00000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x36/0x90\n ? exc_general_protection+0x1c1/0x3f0\n ? asm_exc_general_protection+0x26/0x30\n ? __list_del_entry_valid_or_report+0x33/0xf0\n __cifs_put_smb_ses+0x1ae/0x500 [cifs]\n smb2_reconnect_server+0x4ed/0x710 [cifs]\n process_one_work+0x205/0x6b0\n worker_thread+0x191/0x360\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xe2/0x110\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-35870)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: fix use-after-free bugs caused by ax25_ds_del_timer\r\n\r\nWhen the ax25 device is detaching, the ax25_dev_device_down()\ncalls ax25_ds_del_timer() to cleanup the slave_timer. When\nthe timer handler is running, the ax25_ds_del_timer() that\ncalls del_timer() in it will return directly. As a result,\nthe use-after-free bugs could happen, one of the scenarios\nis shown below:\r\n\r\n      (Thread 1)          |      (Thread 2)\n                          | ax25_ds_timeout()\nax25_dev_device_down()    |\n  ax25_ds_del_timer()     |\n    del_timer()           |\n  ax25_dev_put() //FREE   |\n                          |  ax25_dev-\u0026gt; //USE\r\n\r\nIn order to mitigate bugs, when the device is detaching, use\ntimer_shutdown_sync() to stop the timer.(CVE-2024-35887)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: properly terminate timers for kernel sockets\r\n\r\nWe had various syzbot reports about tcp timers firing after\nthe corresponding netns has been dismantled.\r\n\r\nFortunately Josef Bacik could trigger the issue more often,\nand could test a patch I wrote two years ago.\r\n\r\nWhen TCP sockets are closed, we call inet_csk_clear_xmit_timers()\nto \u0026apos;stop\u0026apos; the timers.\r\n\r\ninet_csk_clear_xmit_timers() can be called from any context,\nincluding when socket lock is held.\nThis is the reason it uses sk_stop_timer(), aka del_timer().\nThis means that ongoing timers might finish much later.\r\n\r\nFor user sockets, this is fine because each running timer\nholds a reference on the socket, and the user socket holds\na reference on the netns.\r\n\r\nFor kernel sockets, we risk that the netns is freed before\ntimer can complete, because kernel sockets do not hold\nreference on the netns.\r\n\r\nThis patch adds inet_csk_clear_xmit_timers_sync() function\nthat using sk_stop_timer_sync() to make sure all timers\nare terminated before the kernel socket is released.\nModules using kernel sockets close them in their netns exit()\nhandler.\r\n\r\nAlso add sock_not_owned_by_me() helper to get LOCKDEP\nsupport : inet_csk_clear_xmit_timers_sync() must not be called\nwhile socket lock is held.\r\n\r\nIt is very possible we can revert in the future commit\n3a58f13a881e (\u0026quot;net: rds: acquire refcount on TCP sockets\u0026quot;)\nwhich attempted to solve the issue in rds only.\n(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)\r\n\r\nWe probably can remove the check_net() tests from\ntcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\r\n\r\nsyzbot reported the following uninit-value access issue [1][2]:\r\n\r\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\r\n\r\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes.(CVE-2024-35915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vc4: don\u0026apos;t check if plane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb\r\n\r\nCurrently, when using non-blocking commits, we can see the following\nkernel warning:\r\n\r\n[  110.908514] ------------[ cut here ]------------\n[  110.908529] refcount_t: underflow; use-after-free.\n[  110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0\n[  110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6\n[  110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G         C         6.1.66-v8+ #32\n[  110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[  110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  110.909132] pc : refcount_dec_not_one+0xb8/0xc0\n[  110.909152] lr : refcount_dec_not_one+0xb4/0xc0\n[  110.909170] sp : ffffffc00913b9c0\n[  110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60\n[  110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480\n[  110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78\n[  110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000\n[  110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004\n[  110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003\n[  110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00\n[  110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572\n[  110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000\n[  110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001\n[  110.909434] Call trace:\n[  110.909441]  refcount_dec_not_one+0xb8/0xc0\n[  110.909461]  vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]\n[  110.909903]  vc4_cleanup_fb+0x44/0x50 [vc4]\n[  110.910315]  drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]\n[  110.910669]  vc4_atomic_commit_tail+0x390/0x9dc [vc4]\n[  110.911079]  commit_tail+0xb0/0x164 [drm_kms_helper]\n[  110.911397]  drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]\n[  110.911716]  drm_atomic_commit+0xb0/0xdc [drm]\n[  110.912569]  drm_mode_atomic_ioctl+0x348/0x4b8 [drm]\n[  110.913330]  drm_ioctl_kernel+0xec/0x15c [drm]\n[  110.914091]  drm_ioctl+0x24c/0x3b0 [drm]\n[  110.914850]  __arm64_sys_ioctl+0x9c/0xd4\n[  110.914873]  invoke_syscall+0x4c/0x114\n[  110.914897]  el0_svc_common+0xd0/0x118\n[  110.914917]  do_el0_svc+0x38/0xd0\n[  110.914936]  el0_svc+0x30/0x8c\n[  110.914958]  el0t_64_sync_handler+0x84/0xf0\n[  110.914979]  el0t_64_sync+0x18c/0x190\n[  110.914996] ---[ end trace 0000000000000000 ]---\r\n\r\nThis happens because, although `prepare_fb` and `cleanup_fb` are\nperfectly balanced, we cannot guarantee consistency in the check\nplane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb. This means that sometimes we can increase\nthe refcount in `prepare_fb` and don\u0026apos;t decrease it in `cleanup_fb`. The\nopposite can also be true.\r\n\r\nIn fact, the struct drm_plane .state shouldn\u0026apos;t be accessed directly\nbut instead, the `drm_atomic_get_new_plane_state()` helper function should\nbe used. So, we could stick to this check, but using\n`drm_atomic_get_new_plane_state()`. But actually, this check is not re\n---truncated---(CVE-2024-35932)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: send: handle path ref underflow in header iterate_inode_ref()\r\n\r\nChange BUG_ON to proper error handling if building the path buffer\nfails. The pointers are not printed so we don\u0026apos;t accidentally leak kernel\naddresses.(CVE-2024-35935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: check A-MSDU format more carefully\r\n\r\nIf it looks like there\u0026apos;s another subframe in the A-MSDU\nbut the header isn\u0026apos;t fully there, we can end up reading\ndata out of bounds, only to discard later. Make this a\nbit more careful and check if the subframe header can\neven be present.(CVE-2024-35937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()\r\n\r\nSubject: [PATCH] drm/panfrost: Fix the error path in\n panfrost_mmu_map_fault_addr()\r\n\r\nIf some the pages or sgt allocation failed, we shouldn\u0026apos;t release the\npages ref we got earlier, otherwise we will end up with unbalanced\nget/put_pages() calls. We should instead leave everything in place\nand let the BO release function deal with extra cleanup when the object\nis destroyed, or let the fault handler try again next time it\u0026apos;s called.(CVE-2024-35951)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix not validating setsockopt user input\r\n\r\nCheck user input length before copying data.(CVE-2024-35965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: RFCOMM: Fix not validating setsockopt user input\r\n\r\nsyzbot reported rfcomm_sock_setsockopt_old() is copying data without\nchecking user input length.\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset\ninclude/linux/sockptr.h:49 [inline]\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr\ninclude/linux/sockptr.h:55 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old\nnet/bluetooth/rfcomm/sock.c:632 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70\nnet/bluetooth/rfcomm/sock.c:673\nRead of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: fix possible out-of-bounds in gsm0_receive()\r\n\r\nAssuming the following:\n- side A configures the n_gsm in basic option mode\n- side B sends the header of a basic option mode frame with data length 1\n- side A switches to advanced option mode\n- side B sends 2 data bytes which exceeds gsm-\u0026gt;len\n  Reason: gsm-\u0026gt;len is not used in advanced option mode.\n- side A switches to basic option mode\n- side B keeps sending until gsm0_receive() writes past gsm-\u0026gt;buf\n  Reason: Neither gsm-\u0026gt;state nor gsm-\u0026gt;len have been reset after\n  reconfiguration.\r\n\r\nFix this by changing gsm-\u0026gt;count to gsm-\u0026gt;len comparison from equal to less\nthan. Also add upper limit checks against the constant MAX_MRU in\ngsm0_receive() and gsm1_receive() to harden against memory corruption of\ngsm-\u0026gt;len and gsm-\u0026gt;mru.\r\n\r\nAll other checks remain as we still need to limit the data according to the\nuser configuration and actual payload size.(CVE-2024-36016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets\r\n\r\nTCP_SYN_RECV state is really special, it is only used by\ncross-syn connections, mostly used by fuzzers.\r\n\r\nIn the following crash [1], syzbot managed to trigger a divide\nby zero in tcp_rcv_space_adjust()\r\n\r\nA socket makes the following state transitions,\nwithout ever calling tcp_init_transfer(),\nmeaning tcp_init_buffer_space() is also not called.\r\n\r\n         TCP_CLOSE\nconnect()\n         TCP_SYN_SENT\n         TCP_SYN_RECV\nshutdown() -\u0026gt; tcp_shutdown(sk, SEND_SHUTDOWN)\n         TCP_FIN_WAIT1\r\n\r\nTo fix this issue, change tcp_shutdown() to not\nperform a TCP_SYN_RECV -\u0026gt; TCP_FIN_WAIT1 transition,\nwhich makes no sense anyway.\r\n\r\nWhen tcp_rcv_state_process() later changes socket state\nfrom TCP_SYN_RECV to TCP_ESTABLISH, then look at\nsk-\u0026gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,\nand send a FIN packet from a sane socket state.\r\n\r\nThis means tcp_send_fin() can now be called from BH\ncontext, and must use GFP_ATOMIC allocations.\r\n\r\n[1]\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767\nCode: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 \u0026lt;48\u0026gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48\nRSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246\nRAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7\nR10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30\nR13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da\nFS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513\n  tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578\n  inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680\n  sock_recvmsg_nosec net/socket.c:1046 [inline]\n  sock_recvmsg+0x109/0x280 net/socket.c:1068\n  ____sys_recvmsg+0x1db/0x470 net/socket.c:2803\n  ___sys_recvmsg net/socket.c:2845 [inline]\n  do_recvmmsg+0x474/0xae0 net/socket.c:2939\n  __sys_recvmmsg net/socket.c:3018 [inline]\n  __do_sys_recvmmsg net/socket.c:3041 [inline]\n  __se_sys_recvmmsg net/socket.c:3034 [inline]\n  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7faeb6363db9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9\nRDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c\nR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-iocost: avoid out of bounds shift\r\n\r\nUBSAN catches undefined behavior in blk-iocost, where sometimes\niocg-\u0026gt;delay is shifted right by a number that is too large,\nresulting in undefined behavior on some architectures.\r\n\r\n[  186.556576] ------------[ cut here ]------------\nUBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23\nshift exponent 64 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;)\nCPU: 16 PID: 0 Comm: swapper/16 Tainted: G S          E    N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1\nHardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x8f/0xe0\n __ubsan_handle_shift_out_of_bounds+0x22c/0x280\n iocg_kick_delay+0x30b/0x310\n ioc_timer_fn+0x2fb/0x1f80\n __run_timer_base+0x1b6/0x250\n...\r\n\r\nAvoid that undefined behavior by simply taking the\n\u0026quot;delay = 0\u0026quot; branch if the shift is too large.\r\n\r\nI am not sure what the symptoms of an undefined value\ndelay will be, but I suspect it could be more than a\nlittle annoying to debug.(CVE-2024-36916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\r\n\r\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won\u0026apos;t be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\r\n\r\nThis will suppress following BUG_ON():\r\n\r\n[  449.843143] ------------[ cut here ]------------\n[  449.848302] kernel BUG at mm/vmalloc.c:2727!\n[  449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[  449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[  449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[  449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[  449.882910] RIP: 0010:vunmap+0x2e/0x30\n[  449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 \u0026lt;0f\u0026gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[  449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[  449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[  449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[  449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[  449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[  449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[  449.953701] FS:  0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[  449.962732] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[  449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  449.993028] Call Trace:\n[  449.995756]  __iommu_dma_free+0x96/0x100\n[  450.000139]  bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[  450.006171]  bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[  450.011910]  bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[  450.018136]  fc_rport_work+0x103/0x5b0 [libfc]\n[  450.023103]  process_one_work+0x1e8/0x3c0\n[  450.027581]  worker_thread+0x50/0x3b0\n[  450.031669]  ? rescuer_thread+0x370/0x370\n[  450.036143]  kthread+0x149/0x170\n[  450.039744]  ? set_kthread_struct+0x40/0x40\n[  450.044411]  ret_from_fork+0x22/0x30\n[  450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[  450.048497]  libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[  450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Move NPIV\u0026apos;s transport unregistration to after resource clean up\r\n\r\nThere are cases after NPIV deletion where the fabric switch still believes\nthe NPIV is logged into the fabric.  This occurs when a vport is\nunregistered before the Remove All DA_ID CT and LOGO ELS are sent to the\nfabric.\r\n\r\nCurrently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including\nthe fabric D_ID, removes the last ndlp reference and frees the ndlp rport\nobject.  This sometimes causes the race condition where the final DA_ID and\nLOGO are skipped from being sent to the fabric switch.\r\n\r\nFix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID\nand LOGO are sent.(CVE-2024-36952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix invalid reads in fence signaled events\r\n\r\nCorrectly set the length of the drm_event to the size of the structure\nthat\u0026apos;s actually used.\r\n\r\nThe length of the drm_event was set to the parent structure instead of\nto the drm_vmw_event_fence which is supposed to be read. drm_read\nuses the length parameter to copy the event to the user space thus\nresuling in oob reads.(CVE-2024-36960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()\r\n\r\nl2cap_le_flowctl_init() can cause both div-by-zero and an integer\noverflow since hdev-\u0026gt;le_mtu may not fall in the valid range.\r\n\r\nMove MTU from hci_dev to hci_conn to validate MTU and stop the connection\nprocess earlier if MTU is invalid.\nAlso, add a missing validation in read_buffer_size() and make it return\nan error value if the validation fails.\nNow hci_conn_add() returns ERR_PTR() as it can fail due to the both a\nkzalloc failure and invalid MTU value.\r\n\r\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nWorkqueue: hci0 hci_rx_work\nRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547\nCode: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c\n89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 \u0026lt;66\u0026gt; f7 f3 89 c3 ff c3 4d 8d\nb7 88 00 00 00 4c 89 f0 48 c1 e8 03 42\nRSP: 0018:ffff88810bc0f858 EFLAGS: 00010246\nRAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f\nRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa\nR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084\nR13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000\nFS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]\n l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]\n l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]\n l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809\n l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506\n hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]\n hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335\n worker_thread+0x926/0xe70 kernel/workqueue.c:3416\n kthread+0x2e3/0x380 kernel/kthread.c:388\n ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---(CVE-2024-36968)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix __dst_negative_advice() race\r\n\r\n__dst_negative_advice() does not enforce proper RCU rules when\nsk-\u0026gt;dst_cache must be cleared, leading to possible UAF.\r\n\r\nRCU rules are that we must first clear sk-\u0026gt;sk_dst_cache,\nthen call dst_release(old_dst).\r\n\r\nNote that sk_dst_reset(sk) is implementing this protocol correctly,\nwhile __dst_negative_advice() uses the wrong order.\r\n\r\nGiven that ip6_negative_advice() has special logic\nagainst RTF_CACHE, this means each of the three -\u0026gt;negative_advice()\nexisting methods must perform the sk_dst_reset() themselves.\r\n\r\nNote the check against NULL dst is centralized in\n__dst_negative_advice(), there is no need to duplicate\nit in various callbacks.\r\n\r\nMany thanks to Clement Lecigne for tracking this issue.\r\n\r\nThis old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)",
  "id": "OESA-2024-1738",
  "modified": "2026-08-06T11:07:12Z",
  "published": "2024-06-21T11:07:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47366"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48692"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52670"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52748"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52791"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52841"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52873"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52882"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26935"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26936"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27017"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27044"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35796"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35819"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35870"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35887"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35910"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35915"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35932"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35935"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35937"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35951"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35966"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36905"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36916"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36919"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36971"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47366",
    "CVE-2022-48673",
    "CVE-2022-48692",
    "CVE-2023-52670",
    "CVE-2023-52748",
    "CVE-2023-52791",
    "CVE-2023-52821",
    "CVE-2023-52841",
    "CVE-2023-52873",
    "CVE-2023-52882",
    "CVE-2024-26924",
    "CVE-2024-26935",
    "CVE-2024-26936",
    "CVE-2024-26947",
    "CVE-2024-26954",
    "CVE-2024-26960",
    "CVE-2024-27014",
    "CVE-2024-27017",
    "CVE-2024-27019",
    "CVE-2024-27044",
    "CVE-2024-35796",
    "CVE-2024-35819",
    "CVE-2024-35821",
    "CVE-2024-35828",
    "CVE-2024-35870",
    "CVE-2024-35887",
    "CVE-2024-35910",
    "CVE-2024-35915",
    "CVE-2024-35932",
    "CVE-2024-35935",
    "CVE-2024-35937",
    "CVE-2024-35951",
    "CVE-2024-35965",
    "CVE-2024-35966",
    "CVE-2024-36016",
    "CVE-2024-36905",
    "CVE-2024-36916",
    "CVE-2024-36919",
    "CVE-2024-36952",
    "CVE-2024-36960",
    "CVE-2024-36968",
    "CVE-2024-36971"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.83.0.164.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.83.0.164.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.83.0.164.oe2203sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: Set page uptodate in the correct place\r\n\r\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we\u0026apos;ve overwritten it with the data it\u0026apos;s supposed to have\nin it will allow a simultaneous reader to see old data.  Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page.(CVE-2024-35821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkprobes: Fix possible use-after-free issue on kprobe registration\r\n\r\nWhen unloading a module, its state is changing MODULE_STATE_LIVE -\u0026gt;\n MODULE_STATE_GOING -\u0026gt; MODULE_STATE_UNFORMED. Each change will take\na time. `is_module_text_address()` and `__module_text_address()`\nworks with MODULE_STATE_LIVE and MODULE_STATE_GOING.\nIf we use `is_module_text_address()` and `__module_text_address()`\nseparately, there is a chance that the first one is succeeded but the\nnext one is failed because module-\u0026gt;state becomes MODULE_STATE_UNFORMED\nbetween those operations.\r\n\r\nIn `check_kprobe_address_safe()`, if the second `__module_text_address()`\nis failed, that is ignored because it expected a kernel_text address.\nBut it may have failed simply because module-\u0026gt;state has been changed\nto MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify\nnon-exist module text address (use-after-free).\r\n\r\nTo fix this problem, we should not use separated `is_module_text_address()`\nand `__module_text_address()`, but use only `__module_text_address()`\nonce and do `try_module_get(module)` which is only available with\nMODULE_STATE_LIVE.(CVE-2024-35955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP\r\n\r\nIf one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,\ntaprio_parse_mqprio_opt() must validate it, or userspace\ncan inject arbitrary data to the kernel, the second time\ntaprio_change() is called.\r\n\r\nFirst call (with valid attributes) sets dev-\u0026gt;num_tc\nto a non zero value.\r\n\r\nSecond call (with arbitrary mqprio attributes)\nreturns early from taprio_parse_mqprio_opt()\nand bad things can happen.(CVE-2024-36974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: Fix shift-out-of-bounds in dctcp_update_alpha().\r\n\r\nIn dctcp_update_alpha(), we use a module parameter dctcp_shift_g\nas follows:\r\n\r\n  alpha -= min_not_zero(alpha, alpha \u0026gt;\u0026gt; dctcp_shift_g);\n  ...\n  delivered_ce \u0026lt;\u0026lt;= (10 - dctcp_shift_g);\r\n\r\nIt seems syzkaller started fuzzing module parameters and triggered\nshift-out-of-bounds [0] by setting 100 to dctcp_shift_g:\r\n\r\n  memcpy((void*)0x20000080,\n         \u0026quot;/sys/module/tcp_dctcp/parameters/dctcp_shift_g\\000\u0026quot;, 47);\n  res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,\n                /*flags=*/2ul, /*mode=*/0ul);\n  memcpy((void*)0x20000000, \u0026quot;100\\000\u0026quot;, 4);\n  syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);\r\n\r\nLet\u0026apos;s limit the max value of dctcp_shift_g by param_set_uint_minmax().\r\n\r\nWith this patch:\r\n\r\n  # echo 10 \u0026gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n  # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n  10\n  # echo 11 \u0026gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n  -bash: echo: write error: Invalid argument\r\n\r\n[0]:\nUBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12\nshift exponent 100 is too large for 32-bit type \u0026apos;u32\u0026apos; (aka \u0026apos;unsigned int\u0026apos;)\nCPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468\n dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143\n tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]\n tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948\n tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711\n tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937\n sk_backlog_rcv include/net/sock.h:1106 [inline]\n __release_sock+0x20f/0x350 net/core/sock.c:2983\n release_sock+0x61/0x1f0 net/core/sock.c:3549\n mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907\n mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976\n __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072\n mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127\n inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437\n __sock_release net/socket.c:659 [inline]\n sock_close+0xc0/0x240 net/socket.c:1421\n __fput+0x41b/0x890 fs/file_table.c:422\n task_work_run+0x23b/0x300 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x9c8/0x2540 kernel/exit.c:878\n do_group_exit+0x201/0x2b0 kernel/exit.c:1027\n __do_sys_exit_group kernel/exit.c:1038 [inline]\n __se_sys_exit_group kernel/exit.c:1036 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x67/0x6f\nRIP: 0033:0x7f6c2b5005b6\nCode: Unable to access opcode bytes at 0x7f6c2b50058c.\nRSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6\nRDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001\nRBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0\nR10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0\nR13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n \u0026lt;/TASK\u0026gt;(CVE-2024-37356)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: add buffer overflow check in of_modalias()\r\n\r\nIn of_modalias(), if the buffer happens to be too small even for the 1st\nsnprintf() call, the len parameter will become negative and str parameter\n(if not NULL initially) will point beyond the buffer\u0026apos;s end. Add the buffer\noverflow check after the 1st snprintf() call and fix such check after the\nstrlen() call (accounting for the terminating NUL char).(CVE-2024-38541)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Add a timeout to acquire the command queue semaphore\r\n\r\nPrevent forced completion handling on an entry that has not yet been\nassigned an index, causing an out of bounds access on idx = -22.\nInstead of waiting indefinitely for the sem, blocking flow now waits for\nindex to be allocated or a sem acquisition timeout before beginning the\ntimer for FW completion.\r\n\r\nKernel log example:\nmlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion(CVE-2024-38556)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE\r\n\r\nbpf_prog_attach uses attach_type_to_prog_type to enforce proper\nattach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses\nbpf_prog_get and relies on bpf_prog_attach_check_attach_type\nto properly verify prog_type \u0026lt;\u0026gt; attach_type association.\r\n\r\nAdd missing attach_type enforcement for the link_create case.\nOtherwise, it\u0026apos;s currently possible to attach cgroup_skb prog\ntypes to other cgroup hooks.(CVE-2024-38564)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nftrace: Fix possible use-after-free issue in ftrace_location()\r\n\r\nKASAN reports a bug:\r\n\r\n  BUG: KASAN: use-after-free in ftrace_location+0x90/0x120\n  Read of size 8 at addr ffff888141d40010 by task insmod/424\n  CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+\n  [...]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x68/0xa0\n   print_report+0xcf/0x610\n   kasan_report+0xb5/0xe0\n   ftrace_location+0x90/0x120\n   register_kprobe+0x14b/0xa40\n   kprobe_init+0x2d/0xff0 [kprobe_example]\n   do_one_initcall+0x8f/0x2d0\n   do_init_module+0x13a/0x3c0\n   load_module+0x3082/0x33d0\n   init_module_from_file+0xd2/0x130\n   __x64_sys_finit_module+0x306/0x440\n   do_syscall_64+0x68/0x140\n   entry_SYSCALL_64_after_hwframe+0x71/0x79\r\n\r\nThe root cause is that, in lookup_rec(), ftrace record of some address\nis being searched in ftrace pages of some module, but those ftrace pages\nat the same time is being freed in ftrace_release_mod() as the\ncorresponding module is being deleted:\r\n\r\n           CPU1                       |      CPU2\n  register_kprobes() {                | delete_module() {\n    check_kprobe_address_safe() {     |\n      arch_check_ftrace_location() {  |\n        ftrace_location() {           |\n          lookup_rec() // USE!        |   ftrace_release_mod() // Free!\r\n\r\nTo fix this issue:\n  1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();\n  2. Use ftrace_location_range() instead of lookup_rec() in\n     ftrace_location();\n  3. Call synchronize_rcu() before freeing any ftrace pages both in\n     ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().(CVE-2024-38588)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njffs2: prevent xattr node from overflowing the eraseblock\r\n\r\nAdd a check to make sure that the requested xattr node size is no larger\nthan the eraseblock minus the cleanmarker.\r\n\r\nUnlike the usual inode nodes, the xattr nodes aren\u0026apos;t split into parts\nand spread across multiple eraseblocks, which means that a xattr node\nmust not occupy more than one eraseblock. If the requested xattr value is\ntoo large, the xattr node can spill onto the next eraseblock, overwriting\nthe nodes and causing errors such as:\r\n\r\njffs2: argh. node added in wrong place at 0x0000b050(2)\njffs2: nextblock 0x0000a000, expected at 0000b00c\njffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,\nread=0xfc892c93, calc=0x000000\njffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed\nat 0x01e00c. {848f,2fc4,0fef511f,59a3d171}\njffs2: Node at 0x0000000c with length 0x00001044 would run over the\nend of the erase block\njffs2: Perhaps the file system was created with the wrong erase size?\njffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found\nat 0x00000010: 0x1044 instead\r\n\r\nThis breaks the filesystem and can lead to KASAN crashes such as:\r\n\r\nBUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0\nRead of size 4 at addr ffff88802c31e914 by task repro/830\nCPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS Arch Linux 1.16.3-1-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xc4/0x620\n ? __virt_addr_valid+0x308/0x5b0\n kasan_report+0xc1/0xf0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_flash_direct_writev+0xa8/0xd0\n jffs2_flash_writev+0x9c9/0xef0\n ? __x64_sys_setxattr+0xc4/0x160\n ? do_syscall_64+0x69/0x140\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Use variable length array instead of fixed size\r\n\r\nShould fix smatch warning:\n\tntfs_set_label() error: __builtin_memcpy() \u0026apos;uni-\u0026gt;name\u0026apos; too small (20 vs 256)(CVE-2024-38623)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Use 64 bit variable to avoid 32 bit overflow\r\n\r\nFor example, in the expression:\n\tvbo = 2 * vbo + skip(CVE-2024-38624)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger\r\n\r\nWhen the cpu5wdt module is removing, the origin code uses del_timer() to\nde-activate the timer. If the timer handler is running, del_timer() could\nnot stop it and will return directly. If the port region is released by\nrelease_region() and then the timer handler cpu5wdt_trigger() calls outb()\nto write into the region that is released, the use-after-free bug will\nhappen.\r\n\r\nChange del_timer() to timer_shutdown_sync() in order that the timer handler\ncould be finished before the port region is released.(CVE-2024-38630)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/ap: Fix crash in AP internal function modify_bitmap()\r\n\r\nA system crash like this\r\n\r\n  Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403\n  Fault in home space mode while using kernel ASCE.\n  AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d\n  Oops: 0038 ilc:3 [#1] PREEMPT SMP\n  Modules linked in: mlx5_ib ...\n  CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8\n  Hardware name: IBM 3931 A01 704 (LPAR)\n  Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)\n  R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3\n  Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3\n  000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0\n  000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff\n  000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8\n  Krnl Code: 0000014b75e7b5fc: a7840047            brc     8,0000014b75e7b68a\n  0000014b75e7b600: 18b2                lr      %r11,%r2\n  #0000014b75e7b602: a7f4000a            brc     15,0000014b75e7b616\n  \u0026gt;0000014b75e7b606: eb22d00000e6        laog    %r2,%r2,0(%r13)\n  0000014b75e7b60c: a7680001            lhi     %r6,1\n  0000014b75e7b610: 187b                lr      %r7,%r11\n  0000014b75e7b612: 84960021            brxh    %r9,%r6,0000014b75e7b654\n  0000014b75e7b616: 18e9                lr      %r14,%r9\n  Call Trace:\n  [\u0026lt;0000014b75e7b606\u0026gt;] ap_parse_bitmap_str+0x10e/0x1f8\n  ([\u0026lt;0000014b75e7b5dc\u0026gt;] ap_parse_bitmap_str+0xe4/0x1f8)\n  [\u0026lt;0000014b75e7b758\u0026gt;] apmask_store+0x68/0x140\n  [\u0026lt;0000014b75679196\u0026gt;] kernfs_fop_write_iter+0x14e/0x1e8\n  [\u0026lt;0000014b75598524\u0026gt;] vfs_write+0x1b4/0x448\n  [\u0026lt;0000014b7559894c\u0026gt;] ksys_write+0x74/0x100\n  [\u0026lt;0000014b7618a440\u0026gt;] __do_syscall+0x268/0x328\n  [\u0026lt;0000014b761a3558\u0026gt;] system_call+0x70/0x98\n  INFO: lockdep is turned off.\n  Last Breaking-Event-Address:\n  [\u0026lt;0000014b75e7b636\u0026gt;] ap_parse_bitmap_str+0x13e/0x1f8\n  Kernel panic - not syncing: Fatal exception: panic_on_oops\r\n\r\noccured when /sys/bus/ap/a[pq]mask was updated with a relative mask value\n(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.\r\n\r\nThe fix is simple: use unsigned long values for the internal variables. The\ncorrect checks are already in place in the function but a simple int for\nthe internal variables was used with the possibility to overflow.(CVE-2024-38661)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: Add winch to winch_handlers before registering winch IRQ\r\n\r\nRegistering a winch IRQ is racy, an interrupt may occur before the winch is\nadded to the winch_handlers list.\r\n\r\nIf that happens, register_winch_irq() adds to that list a winch that is\nscheduled to be (or has already been) freed, causing a panic later in\nwinch_cleanup().\r\n\r\nAvoid the race by adding the winch to the winch_handlers list before\nregistering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)",
  "id": "OESA-2024-1796",
  "modified": "2026-08-06T11:07:15Z",
  "published": "2024-07-05T11:07:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1796"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35955"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36974"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37356"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38541"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38556"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38564"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38588"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38599"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38623"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38624"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38630"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38661"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39292"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-35821",
    "CVE-2024-35955",
    "CVE-2024-36974",
    "CVE-2024-37356",
    "CVE-2024-38541",
    "CVE-2024-38556",
    "CVE-2024-38564",
    "CVE-2024-38588",
    "CVE-2024-38599",
    "CVE-2024-38623",
    "CVE-2024-38624",
    "CVE-2024-38630",
    "CVE-2024-38661",
    "CVE-2024-39292"
  ]
}