2184 lines
267 KiB
JSON
2184 lines
267 KiB
JSON
{
|
|
"Definition": [
|
|
{
|
|
"ID": "oval:org.altlinux.errata:def:202412537",
|
|
"Version": "oval:org.altlinux.errata:def:202412537",
|
|
"Class": "patch",
|
|
"Metadata": {
|
|
"Title": "ALT-PU-2024-12537: package `kernel-image-un-def` update to version 5.10.226-alt1",
|
|
"AffectedList": [
|
|
{
|
|
"Family": "unix",
|
|
"Platforms": [
|
|
"ALT Linux branch p9"
|
|
],
|
|
"Products": [
|
|
"ALT Server",
|
|
"ALT Virtualization Server",
|
|
"ALT Workstation",
|
|
"ALT Workstation K",
|
|
"ALT Education",
|
|
"Simply Linux",
|
|
"Starterkit"
|
|
]
|
|
}
|
|
],
|
|
"References": [
|
|
{
|
|
"RefID": "ALT-PU-2024-12537",
|
|
"RefURL": "https://errata.altlinux.org/ALT-PU-2024-12537",
|
|
"Source": "ALTPU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-04680",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-04680",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-05829",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-05829",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-05830",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-05830",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-06063",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-06063",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-06072",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-06072",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-06082",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-06082",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-06732",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-06732",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-06745",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-06745",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-07483",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-07483",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "BDU:2024-07484",
|
|
"RefURL": "https://bdu.fstec.ru/vul/2024-07484",
|
|
"Source": "BDU"
|
|
},
|
|
{
|
|
"RefID": "CVE-2023-52889",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2023-52889",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-36978",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-36978",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-39468",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-39468",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-39482",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-39482",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-39484",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-39484",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-39487",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-39487",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-39495",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-39495",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-39506",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-39506",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40902",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40904",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40904",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40905",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40905",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40912",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40912",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40932",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40932",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40934",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40934",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40958",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40958",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40959",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40959",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40960",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40960",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40961",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40961",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40980",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40980",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40981",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-40995",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-40995",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41000",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41000",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41006",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41006",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41007",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41007",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41011",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41011",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41012",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41012",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41040",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41040",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41046",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41046",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41049",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41049",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41055",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41055",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41059",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41059",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41063",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41063",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41064",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41064",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41070",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41070",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41087",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41087",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41089",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41089",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41092",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41092",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41095",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41095",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-41097",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-41097",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42070",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42070",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42076",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42076",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42077",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42077",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42082",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42082",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42090",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42090",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42093",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42093",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42094",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42094",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42101",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42101",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42102",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42102",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42104",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42104",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42131",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42131",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42137",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42137",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42148",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42148",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42152",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42152",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42153",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42154",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42157",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42157",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42161",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42161",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42223",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42223",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42224",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42224",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42229",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42229",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42232",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42232",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42236",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42236",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42244",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42244",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42247",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42247",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42259",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42259",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42271",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42271",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42280",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42280",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42283",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42283",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42284",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42284",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42285",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42285",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42286",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42286",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42287",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42287",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42288",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42288",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42289",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42289",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42301",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42301",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42302",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42302",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42308",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42308",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42309",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42309",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42310",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42310",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42311",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42311",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-42313",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-42313",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43828",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43828",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43856",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43856",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43858",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43858",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43860",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43860",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43861",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43861",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43871",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43882",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43882",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43889",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43889",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43890",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43890",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43893",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43893",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43894",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43894",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43907",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43907",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43908",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43908",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-43914",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-43914",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44935",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44935",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44944",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44947",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44947",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44971",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44971",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44987",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44987",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44989",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44989",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44990",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44990",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44995",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44995",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44998",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44998",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-44999",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-44999",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-45006",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-45006",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-45016",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-45016",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-45018",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-45018",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-45021",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-45021",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-45025",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-45025",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-45026",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-45026",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-45028",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-45028",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46673",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46673",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46674",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46674",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46675",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46675",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46676",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46676",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46677",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46677",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46679",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46679",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46685",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46685",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46689",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46689",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46702",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46702",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46707",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46707",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46719",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46719",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46721",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46721",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46722",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46722",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46723",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46723",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46724",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46724",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46725",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46725",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46731",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46731",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46737",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46737",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46738",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46738",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46739",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46739",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46740",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46740",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46743",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46743",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46747",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46747",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46755",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46755",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46756",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46756",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46757",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46757",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46758",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46758",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46759",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46759",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46761",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46761",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46763",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46763",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46781",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46781",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46782",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46782",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46791",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46791",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46798",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46798",
|
|
"Source": "CVE"
|
|
},
|
|
{
|
|
"RefID": "CVE-2024-46800",
|
|
"RefURL": "https://nvd.nist.gov/vuln/detail/CVE-2024-46800",
|
|
"Source": "CVE"
|
|
}
|
|
],
|
|
"Description": "This update upgrades kernel-image-un-def to version 5.10.226-alt1. \nSecurity Fix(es):\n\n * BDU:2024-04680: Уязвимость функции multiq_tune компонента sch_multiq ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код\n\n * BDU:2024-05829: Уязвимость функции kfree_sensitive ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации\n\n * BDU:2024-05830: Уязвимость функции copy_to_user компонента s390 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код\n\n * BDU:2024-06063: Уязвимость функции bond_option_arp_ip_targets_set() сетевой компоненты ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации\n\n * BDU:2024-06072: Уязвимость функции gb_interface_release() драйвера Greybus ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации\n\n * BDU:2024-06082: Уязвимость структуры davinci_mmcsd_driver драйвера MMC/SD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании\n\n * BDU:2024-06732: Уязвимость функции gtp_dev_xmit() модуля drivers/net/gtp.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации\n\n * BDU:2024-06745: Уязвимость функции dequeue_rx() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании\n\n * BDU:2024-07483: Уязвимость функции fcntl_setlk() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации\n\n * BDU:2024-07484: Уязвимость функции criu_restore_memory_of_gpu() драйвера amdkfd ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации\n\n * CVE-2023-52889: In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: Fix null pointer deref when receiving skb during sock creation\n\nThe panic below is observed when receiving ICMP packets with secmark set\nwhile an ICMP raw socket is being created. SK_CTX(sk)-\u003elabel is updated\nin apparmor_socket_post_create(), but the packet is delivered to the\nsocket before that, causing the null pointer dereference.\nDrop the packet if label context is not set.\n\n BUG: kernel NULL pointer dereference, address: 000000000000004c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df\n Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020\n RIP: 0010:aa_label_next_confined+0xb/0x40\n Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 \u003c8b\u003e 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2\n RSP: 0018:ffffa92940003b08 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e\n RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002\n R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400\n R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000\n FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0\n PKRU: 55555554\n Call Trace:\n \u003cIRQ\u003e\n ? __die+0x23/0x70\n ? page_fault_oops+0x171/0x4e0\n ? exc_page_fault+0x7f/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? aa_label_next_confined+0xb/0x40\n apparmor_secmark_check+0xec/0x330\n security_sock_rcv_skb+0x35/0x50\n sk_filter_trim_cap+0x47/0x250\n sock_queue_rcv_skb_reason+0x20/0x60\n raw_rcv+0x13c/0x210\n raw_local_deliver+0x1f3/0x250\n ip_protocol_deliver_rcu+0x4f/0x2f0\n ip_local_deliver_finish+0x76/0xa0\n __netif_receive_skb_one_core+0x89/0xa0\n netif_receive_skb+0x119/0x170\n ? __netdev_alloc_skb+0x3d/0x140\n vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n __napi_poll+0x28/0x1b0\n net_rx_action+0x2a4/0x380\n __do_softirq+0xd1/0x2c8\n __irq_exit_rcu+0xbb/0xf0\n common_interrupt+0x86/0xa0\n \u003c/IRQ\u003e\n \u003cTASK\u003e\n asm_common_interrupt+0x26/0x40\n RIP: 0010:apparmor_socket_post_create+0xb/0x200\n Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 \u003c55\u003e 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48\n RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286\n RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001\n RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740\n RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003\n R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748\n ? __pfx_apparmor_socket_post_create+0x10/0x10\n security_socket_post_create+0x4b/0x80\n __sock_create+0x176/0x1f0\n __sys_socket+0x89/0x100\n __x64_sys_socket+0x17/0x20\n do_syscall_64+0x5d/0x90\n ? do_syscall_64+0x6c/0x90\n ? do_syscall_64+0x6c/0x90\n ? do_syscall_64+0x6c/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\n * CVE-2024-36978: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: sch_multiq: fix possible OOB write in multiq_tune()\n\nq-\u003ebands will be assigned to qopt-\u003ebands to execute subsequent code logic\nafter kmalloc. So the old q-\u003ebands should not be used in kmalloc.\nOtherwise, an out-of-bounds write will occur.\n\n * CVE-2024-39468: In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix deadlock in smb2_find_smb_tcon()\n\nUnlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such\ndeadlock.\n\n * CVE-2024-39482: In the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix variable length array abuse in btree_iter\n\nbtree_iter is used in two ways: either allocated on the stack with a\nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the\nspecific cache set. Previously, the struct had a fixed-length array of\nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized\niterators, which causes UBSAN to complain.\n\nThis patch uses the same approach as in bcachefs's sort_iter and splits\nthe iterator into a btree_iter with a flexible array member and a\nbtree_iter_stack which embeds a btree_iter as well as a fixed-length\ndata array.\n\n * CVE-2024-39484: In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: davinci: Don't strip remove function when driver is builtin\n\nUsing __exit for the remove function results in the remove callback being\ndiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.\nusing sysfs or hotplug), the driver is just removed without the cleanup\nbeing performed. This results in resource leaks. Fix it by compiling in the\nremove callback unconditionally.\n\nThis also fixes a W=1 modpost warning:\n\nWARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in\nreference: davinci_mmcsd_driver+0x10 (section: .data) -\u003e\ndavinci_mmcsd_remove (section: .exit.text)\n\n * CVE-2024-39487: In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()\n\nIn function bond_option_arp_ip_targets_set(), if newval-\u003estring is an\nempty string, newval-\u003estring+1 will point to the byte after the\nstring, causing an out-of-bound read.\n\nBUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418\nRead of size 1 at addr ffff8881119c4781 by task syz-executor665/8107\nCPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:364 [inline]\n print_report+0xc1/0x5e0 mm/kasan/report.c:475\n kasan_report+0xbe/0xf0 mm/kasan/report.c:588\n strlen+0x7d/0xa0 lib/string.c:418\n __fortify_strlen include/linux/fortify-string.h:210 [inline]\n in4_pton+0xa3/0x3f0 net/core/utils.c:130\n bond_option_arp_ip_targets_set+0xc2/0x910\ndrivers/net/bonding/bond_options.c:1201\n __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767\n __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792\n bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817\n bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156\n dev_attr_store+0x54/0x80 drivers/base/core.c:2366\n sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136\n kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x96a/0xd80 fs/read_write.c:584\n ksys_write+0x122/0x250 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n---[ end trace ]---\n\nFix it by adding a check of string length before using it.\n\n * CVE-2024-39495: In the Linux kernel, the following vulnerability has been resolved:\n\ngreybus: Fix use-after-free bug in gb_interface_release due to race condition.\n\nIn gb_interface_create, \u0026intf-\u003emode_switch_completion is bound with\ngb_interface_mode_switch_work. Then it will be started by\ngb_interface_request_mode_switch. Here is the relevant code.\nif (!queue_work(system_long_wq, \u0026intf-\u003emode_switch_work)) {\n\t...\n}\n\nIf we call gb_interface_release to make cleanup, there may be an\nunfinished work. This function will call kfree to free the object\n\"intf\". However, if gb_interface_mode_switch_work is scheduled to\nrun after kfree, it may cause use-after-free error as\ngb_interface_mode_switch_work will use the object \"intf\".\nThe possible execution flow that may lead to the issue is as follows:\n\nCPU0 CPU1\n\n | gb_interface_create\n | gb_interface_request_mode_switch\ngb_interface_release |\nkfree(intf) (free) |\n | gb_interface_mode_switch_work\n | mutex_lock(\u0026intf-\u003emutex) (use)\n\nFix it by canceling the work before kfree.\n\n * CVE-2024-39506: In the Linux kernel, the following vulnerability has been resolved:\n\nliquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet\n\nIn lio_vf_rep_copy_packet() pg_info-\u003epage is compared to a NULL value,\nbut then it is unconditionally passed to skb_add_rx_frag() which looks\nstrange and could lead to null pointer dereference.\n\nlio_vf_rep_copy_packet() call trace looks like:\n\tocteon_droq_process_packets\n\t octeon_droq_fast_process_packets\n\t octeon_droq_dispatch_pkt\n\t octeon_create_recv_info\n\t ...search in the dispatch_list...\n\t -\u003edisp_fn(rdisp-\u003erinfo, ...)\n\t lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)\nIn this path there is no code which sets pg_info-\u003epage to NULL.\nSo this check looks unneeded and doesn't solve potential problem.\nBut I guess the author had reason to add a check and I have no such card\nand can't do real test.\nIn addition, the code in the function liquidio_push_packet() in\nliquidio/lio_core.c does exactly the same.\n\nBased on this, I consider the most acceptable compromise solution to\nadjust this issue by moving skb_add_rx_frag() into conditional scope.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n * CVE-2024-40902: In the Linux kernel, the following vulnerability has been resolved:\n\njfs: xattr: fix buffer overflow for invalid xattr\n\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\n\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log.\n\n * CVE-2024-40904: In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages\n\nThe syzbot fuzzer found that the interrupt-URB completion callback in\nthe cdc-wdm driver was taking too long, and the driver's immediate\nresubmission of interrupt URBs with -EPROTO status combined with the\ndummy-hcd emulation to cause a CPU lockup:\n\ncdc_wdm 1-1:1.0: nonzero urb status received: -71\ncdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes\nwatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]\nCPU#0 Utilization every 4s during lockup:\n\t#1: 98% system,\t 0% softirq,\t 3% hardirq,\t 0% idle\n\t#2: 98% system,\t 0% softirq,\t 3% hardirq,\t 0% idle\n\t#3: 98% system,\t 0% softirq,\t 3% hardirq,\t 0% idle\n\t#4: 98% system,\t 0% softirq,\t 3% hardirq,\t 0% idle\n\t#5: 98% system,\t 1% softirq,\t 3% hardirq,\t 0% idle\nModules linked in:\nirq event stamp: 73096\nhardirqs last enabled at (73095): [\u003cffff80008037bc00\u003e] console_emit_next_record kernel/printk/printk.c:2935 [inline]\nhardirqs last enabled at (73095): [\u003cffff80008037bc00\u003e] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994\nhardirqs last disabled at (73096): [\u003cffff80008af10b00\u003e] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\nhardirqs last disabled at (73096): [\u003cffff80008af10b00\u003e] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\nsoftirqs last enabled at (73048): [\u003cffff8000801ea530\u003e] softirq_handle_end kernel/softirq.c:400 [inline]\nsoftirqs last enabled at (73048): [\u003cffff8000801ea530\u003e] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582\nsoftirqs last disabled at (73043): [\u003cffff800080020de8\u003e] __do_softirq+0x14/0x20 kernel/softirq.c:588\nCPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n\nTesting showed that the problem did not occur if the two error\nmessages -- the first two lines above -- were removed; apparently adding\nmaterial to the kernel log takes a surprisingly large amount of time.\n\nIn any case, the best approach for preventing these lockups and to\navoid spamming the log with thousands of error messages per second is\nto ratelimit the two dev_err() calls. Therefore we replace them with\ndev_err_ratelimited().\n\n * CVE-2024-40905: In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix possible race in __fib6_drop_pcpu_from()\n\nsyzbot found a race in __fib6_drop_pcpu_from() [1]\n\nIf compiler reads more than once (*ppcpu_rt),\nsecond read could read NULL, if another cpu clears\nthe value in rt6_get_pcpu_route().\n\nAdd a READ_ONCE() to prevent this race.\n\nAlso add rcu_read_lock()/rcu_read_unlock() because\nwe rely on RCU protection while dereferencing pcpu_rt.\n\n[1]\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]\nCPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: netns cleanup_net\n RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984\nCode: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 \u003c80\u003e 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48\nRSP: 0018:ffffc900040df070 EFLAGS: 00010206\nRAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16\nRDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091\nRBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007\nR10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8\nR13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001\nFS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]\n fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]\n fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038\n fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]\n fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043\n fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205\n fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127\n fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175\n fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255\n __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271\n rt6_sync_down_dev net/ipv6/route.c:4906 [inline]\n rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911\n addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855\n addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778\n notifier_call_chain+0xb9/0x410 kernel/notifier.c:93\n call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992\n call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]\n call_netdevice_notifiers net/core/dev.c:2044 [inline]\n dev_close_many+0x333/0x6a0 net/core/dev.c:1585\n unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193\n unregister_netdevice_many net/core/dev.c:11276 [inline]\n default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759\n ops_exit_list+0x128/0x180 net/core/net_namespace.c:178\n cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n process_scheduled_works kernel/workqueue.c:3312 [inline]\n worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n kthread+0x2c1/0x3a0 kernel/kthread.c:389\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n * CVE-2024-40912: In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()\n\nThe ieee80211_sta_ps_deliver_wakeup() function takes sta-\u003eps_lock to\nsynchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from\nsoftirq context. However using only spin_lock() to get sta-\u003eps_lock in\nieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute\non this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to\ntake this same lock ending in deadlock. Below is an example of rcu stall\nthat arises in such situation.\n\n rcu: INFO: rcu_sched self-detected stall on CPU\n rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996\n rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4)\n CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742\n Hardware name: RPT (r1) (DT)\n pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : queued_spin_lock_slowpath+0x58/0x2d0\n lr : invoke_tx_handlers_early+0x5b4/0x5c0\n sp : ffff00001ef64660\n x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8\n x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000\n x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000\n x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000\n x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80\n x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da\n x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440\n x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880\n x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8\n Call trace:\n queued_spin_lock_slowpath+0x58/0x2d0\n ieee80211_tx+0x80/0x12c\n ieee80211_tx_pending+0x110/0x278\n tasklet_action_common.constprop.0+0x10c/0x144\n tasklet_action+0x20/0x28\n _stext+0x11c/0x284\n ____do_softirq+0xc/0x14\n call_on_irq_stack+0x24/0x34\n do_softirq_own_stack+0x18/0x20\n do_softirq+0x74/0x7c\n __local_bh_enable_ip+0xa0/0xa4\n _ieee80211_wake_txqs+0x3b0/0x4b8\n __ieee80211_wake_queue+0x12c/0x168\n ieee80211_add_pending_skbs+0xec/0x138\n ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480\n ieee80211_mps_sta_status_update.part.0+0xd8/0x11c\n ieee80211_mps_sta_status_update+0x18/0x24\n sta_apply_parameters+0x3bc/0x4c0\n ieee80211_change_station+0x1b8/0x2dc\n nl80211_set_station+0x444/0x49c\n genl_family_rcv_msg_doit.isra.0+0xa4/0xfc\n genl_rcv_msg+0x1b0/0x244\n netlink_rcv_skb+0x38/0x10c\n genl_rcv+0x34/0x48\n netlink_unicast+0x254/0x2bc\n netlink_sendmsg+0x190/0x3b4\n ____sys_sendmsg+0x1e8/0x218\n ___sys_sendmsg+0x68/0x8c\n __sys_sendmsg+0x44/0x84\n __arm64_sys_sendmsg+0x20/0x28\n do_el0_svc+0x6c/0xe8\n el0_svc+0x14/0x48\n el0t_64_sync_handler+0xb0/0xb4\n el0t_64_sync+0x14c/0x150\n\nUsing spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise\non the same CPU that is holding the lock.\n\n * CVE-2024-40932: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/exynos/vidi: fix memory leak in .get_modes()\n\nThe duplicated EDID is never freed. Fix it.\n\n * CVE-2024-40934: In the Linux kernel, the following vulnerability has been resolved:\n\nHID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()\n\nFix a memory leak on logi_dj_recv_send_report() error path.\n\n * CVE-2024-40958: In the Linux kernel, the following vulnerability has been resolved:\n\nnetns: Make get_net_ns() handle zero refcount net\n\nSyzkaller hit a warning:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0\nModules linked in:\nCPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xdf/0x1d0\nCode: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 \u003c0f\u003e 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1\nRSP: 0018:ffff8881067b7da0 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac\nRDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001\nRBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139\nR10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4\nR13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040\nFS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n ? show_regs+0xa3/0xc0\n ? __warn+0xa5/0x1c0\n ? refcount_warn_saturate+0xdf/0x1d0\n ? report_bug+0x1fc/0x2d0\n ? refcount_warn_saturate+0xdf/0x1d0\n ? handle_bug+0xa1/0x110\n ? exc_invalid_op+0x3c/0xb0\n ? asm_exc_invalid_op+0x1f/0x30\n ? __warn_printk+0xcc/0x140\n ? __warn_printk+0xd5/0x140\n ? refcount_warn_saturate+0xdf/0x1d0\n get_net_ns+0xa4/0xc0\n ? __pfx_get_net_ns+0x10/0x10\n open_related_ns+0x5a/0x130\n __tun_chr_ioctl+0x1616/0x2370\n ? __sanitizer_cov_trace_switch+0x58/0xa0\n ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30\n ? __pfx_tun_chr_ioctl+0x10/0x10\n tun_chr_ioctl+0x2f/0x40\n __x64_sys_ioctl+0x11b/0x160\n x64_sys_call+0x1211/0x20d0\n do_syscall_64+0x9e/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f5b28f165d7\nCode: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8\nRSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7\nRDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003\nRBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0\nR10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730\nR13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000\n \u003c/TASK\u003e\nKernel panic - not syncing: kernel: panic_on_warn set ...\n\nThis is trigger as below:\n ns0 ns1\ntun_set_iff() //dev is tun0\n tun-\u003edev = dev\n//ip link set tun0 netns ns1\n put_net() //ref is 0\n__tun_chr_ioctl() //TUNGETDEVNETNS\n net = dev_net(tun-\u003edev);\n open_related_ns(\u0026net-\u003ens, get_net_ns); //ns1\n get_net_ns()\n get_net() //addition on 0\n\nUse maybe_get_net() in get_net_ns in case net's ref is zero to fix this\n\n * CVE-2024-40959: In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()\n\nip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.\n\nsyzbot reported:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: wg-kex-wg1 wg_packet_handshake_send_worker\n RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64\nCode: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 \u003c80\u003e 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00\nRSP: 0018:ffffc90000117378 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7\nRDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98\nRBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000\nR10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]\n xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]\n xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541\n xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835\n xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]\n xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201\n xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]\n xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309\n ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256\n send6+0x611/0xd20 drivers/net/wireguard/socket.c:139\n wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178\n wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200\n wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40\n wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n process_scheduled_works kernel/workqueue.c:3312 [inline]\n worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n kthread+0x2c1/0x3a0 kernel/kthread.c:389\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n * CVE-2024-40960: In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible NULL dereference in rt6_probe()\n\nsyzbot caught a NULL dereference in rt6_probe() [1]\n\nBail out if __in6_dev_get() returns NULL.\n\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]\nCPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]\n RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758\nCode: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u003c0f\u003e b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19\nRSP: 0018:ffffc900034af070 EFLAGS: 00010203\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000\nRDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c\nRBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a\nR13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000\nFS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784\n nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496\n __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825\n find_rr_leaf net/ipv6/route.c:853 [inline]\n rt6_select net/ipv6/route.c:897 [inline]\n fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195\n ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231\n pol_lookup_func include/net/ip6_fib.h:616 [inline]\n fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121\n ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]\n ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651\n ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147\n ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250\n rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898\n inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_write_iter+0x4b8/0x5c0 net/socket.c:1160\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x6b6/0x1140 fs/read_write.c:590\n ksys_write+0x1f8/0x260 fs/read_write.c:643\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n * CVE-2024-40961: In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible NULL deref in fib6_nh_init()\n\nsyzbot reminds us that in6_dev_get() can return NULL.\n\nfib6_nh_init()\n ip6_validate_gw( \u0026idev )\n ip6_route_check_nh( idev )\n *idev = in6_dev_get(dev); // can be NULL\n\nOops: general 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: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606\nCode: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 \u003c42\u003e 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b\nRSP: 0018:ffffc900032775a0 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000\nRDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8\nRBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000\nR10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8\nR13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000\nFS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809\n ip6_route_add+0x28/0x160 net/ipv6/route.c:3853\n ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483\n inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579\n sock_do_ioctl+0x158/0x460 net/socket.c:1222\n sock_ioctl+0x629/0x8e0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f940f07cea9\n\n * CVE-2024-40980: In the Linux kernel, the following vulnerability has been resolved:\n\ndrop_monitor: replace spin_lock by raw_spin_lock\n\ntrace_drop_common() is called with preemption disabled, and it acquires\na spin_lock. This is problematic for RT kernels because spin_locks are\nsleeping locks in this configuration, which causes the following splat:\n\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47\npreempt_count: 1, expected: 0\nRCU nest depth: 2, expected: 2\n5 locks held by rcuc/47/449:\n #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210\n #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130\n #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210\n #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70\n #4: ff1100086ee07520 (\u0026data-\u003elock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290\nirq event stamp: 139909\nhardirqs last enabled at (139908): [\u003cffffffffb1df2b33\u003e] _raw_spin_unlock_irqrestore+0x63/0x80\nhardirqs last disabled at (139909): [\u003cffffffffb19bd03d\u003e] trace_drop_common.constprop.0+0x26d/0x290\nsoftirqs last enabled at (139892): [\u003cffffffffb07a1083\u003e] __local_bh_enable_ip+0x103/0x170\nsoftirqs last disabled at (139898): [\u003cffffffffb0909b33\u003e] rcu_cpu_kthread+0x93/0x1f0\nPreemption disabled at:\n[\u003cffffffffb1de786b\u003e] rt_mutex_slowunlock+0xab/0x2e0\nCPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7\nHardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x8c/0xd0\n dump_stack+0x14/0x20\n __might_resched+0x21e/0x2f0\n rt_spin_lock+0x5e/0x130\n ? trace_drop_common.constprop.0+0xb5/0x290\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_drop_common.constprop.0+0xb5/0x290\n ? preempt_count_sub+0x1c/0xd0\n ? _raw_spin_unlock_irqrestore+0x4a/0x80\n ? __pfx_trace_drop_common.constprop.0+0x10/0x10\n ? rt_mutex_slowunlock+0x26a/0x2e0\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_rt_mutex_slowunlock+0x10/0x10\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_kfree_skb_hit+0x15/0x20\n trace_kfree_skb+0xe9/0x150\n kfree_skb_reason+0x7b/0x110\n skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10\n ? mark_lock.part.0+0x8a/0x520\n...\n\ntrace_drop_common() also disables interrupts, but this is a minor issue\nbecause we could easily replace it with a local_lock.\n\nReplace the spin_lock with raw_spin_lock to avoid sleeping in atomic\ncontext.\n\n * CVE-2024-40981: In the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: bypass empty buckets in batadv_purge_orig_ref()\n\nMany syzbot reports are pointing to soft lockups in\nbatadv_purge_orig_ref() [1]\n\nRoot cause is unknown, but we can avoid spending too much\ntime there and perhaps get more interesting reports.\n\n[1]\n\nwatchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]\nModules linked in:\nirq event stamp: 6182794\n hardirqs last enabled at (6182793): [\u003cffff8000801dae10\u003e] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\n hardirqs last disabled at (6182794): [\u003cffff80008ad66a78\u003e] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (6182794): [\u003cffff80008ad66a78\u003e] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last enabled at (6182792): [\u003cffff80008aab71c4\u003e] spin_unlock_bh include/linux/spinlock.h:396 [inline]\n softirqs last enabled at (6182792): [\u003cffff80008aab71c4\u003e] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n softirqs last disabled at (6182790): [\u003cffff80008aab61dc\u003e] spin_lock_bh include/linux/spinlock.h:356 [inline]\n softirqs last disabled at (6182790): [\u003cffff80008aab61dc\u003e] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271\nCPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_purge_orig\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]\n pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388\n lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\nsp : ffff800099007970\nx29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000\nx26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001\nx23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4\nx20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0\nx17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001\nx14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003\nx11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000\nCall trace:\n __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]\n arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]\n __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386\n __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210\n spin_unlock_bh include/linux/spinlock.h:396 [inline]\n batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300\n process_one_work+0x694/0x1204 kernel/workqueue.c:2633\n process_scheduled_works kernel/workqueue.c:2706 [inline]\n worker_thread+0x938/0xef4 kernel/workqueue.c:2787\n kthread+0x288/0x310 kernel/kthread.c:388\n ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51\n lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103\nsp : ffff800093a17d30\nx29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4\nx26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002\nx23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000\nx20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396\nx17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001\n---truncated---\n\n * CVE-2024-40995: In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()\n\nsyzbot found hanging tasks waiting on rtnl_lock [1]\n\nA reproducer is available in the syzbot bug.\n\nWhen a request to add multiple actions with the same index is sent, the\nsecond request will block forever on the first request. This holds\nrtnl_lock, and causes tasks to hang.\n\nReturn -EAGAIN to prevent infinite looping, while keeping documented\nbehavior.\n\n[1]\n\nINFO: task kworker/1:0:5088 blocked for more than 143 seconds.\nNot tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0\n\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000\nWorkqueue: events_power_efficient reg_check_chans_work\nCall Trace:\n\u003cTASK\u003e\ncontext_switch kernel/sched/core.c:5409 [inline]\n__schedule+0xf15/0x5d00 kernel/sched/core.c:6746\n__schedule_loop kernel/sched/core.c:6823 [inline]\nschedule+0xe7/0x350 kernel/sched/core.c:6838\nschedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895\n__mutex_lock_common kernel/locking/mutex.c:684 [inline]\n__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752\nwiphy_lock include/net/cfg80211.h:5953 [inline]\nreg_leave_invalid_chans net/wireless/reg.c:2466 [inline]\nreg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481\n\n * CVE-2024-41000: In the Linux kernel, the following vulnerability has been resolved:\n\nblock/ioctl: prefer different overflow check\n\nRunning syzkaller with the newly reintroduced signed integer overflow\nsanitizer shows this report:\n\n[ 62.982337] ------------[ cut here ]------------\n[ 62.985692] cgroup: Invalid name\n[ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46\n[ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1\n[ 62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long'\n[ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1\n[ 62.999369] random: crng reseeded on system resumption\n[ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000)\n[ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1\n[ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 63.000682] Call Trace:\n[ 63.000686] \u003cTASK\u003e\n[ 63.000731] dump_stack_lvl+0x93/0xd0\n[ 63.000919] __get_user_pages+0x903/0xd30\n[ 63.001030] __gup_longterm_locked+0x153e/0x1ba0\n[ 63.001041] ? _raw_read_unlock_irqrestore+0x17/0x50\n[ 63.001072] ? try_get_folio+0x29c/0x2d0\n[ 63.001083] internal_get_user_pages_fast+0x1119/0x1530\n[ 63.001109] iov_iter_extract_pages+0x23b/0x580\n[ 63.001206] bio_iov_iter_get_pages+0x4de/0x1220\n[ 63.001235] iomap_dio_bio_iter+0x9b6/0x1410\n[ 63.001297] __iomap_dio_rw+0xab4/0x1810\n[ 63.001316] iomap_dio_rw+0x45/0xa0\n[ 63.001328] ext4_file_write_iter+0xdde/0x1390\n[ 63.001372] vfs_write+0x599/0xbd0\n[ 63.001394] ksys_write+0xc8/0x190\n[ 63.001403] do_syscall_64+0xd4/0x1b0\n[ 63.001421] ? arch_exit_to_user_mode_prepare+0x3a/0x60\n[ 63.001479] entry_SYSCALL_64_after_hwframe+0x6f/0x77\n[ 63.001535] RIP: 0033:0x7f7fd3ebf539\n[ 63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 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 \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\n[ 63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539\n[ 63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004\n[ 63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000\n[ 63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n[ 63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8\n...\n[ 63.018142] ---[ end trace ]---\n\nHistorically, the signed integer overflow sanitizer did not work in the\nkernel due to its interaction with `-fwrapv` but this has since been\nchanged [1] in the newest version of Clang; It was re-enabled in the\nkernel with Commit 557f8c582a9ba8ab (\"ubsan: Reintroduce signed overflow\nsanitizer\").\n\nLet's rework this overflow checking logic to not actually perform an\noverflow during the check itself, thus avoiding the UBSAN splat.\n\n[1]: https://github.com/llvm/llvm-project/pull/82432\n\n * CVE-2024-41006: In the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: Fix a memory leak in nr_heartbeat_expiry()\n\nsyzbot reported a memory leak in nr_create() [0].\n\nCommit 409db27e3a2e (\"netrom: Fix use-after-free of a listening socket.\")\nadded sock_hold() to the nr_heartbeat_expiry() function, where\na) a socket has a SOCK_DESTROY flag or\nb) a listening socket has a SOCK_DEAD flag.\n\nBut in the case \"a,\" when the SOCK_DESTROY flag is set, the file descriptor\nhas already been closed and the nr_release() function has been called.\nSo it makes no sense to hold the reference count because no one will\ncall another nr_destroy_socket() and put it as in the case \"b.\"\n\nnr_connect\n nr_establish_data_link\n nr_start_heartbeat\n\nnr_release\n switch (nr-\u003estate)\n case NR_STATE_3\n nr-\u003estate = NR_STATE_2\n sock_set_flag(sk, SOCK_DESTROY);\n\n nr_rx_frame\n nr_process_rx_frame\n switch (nr-\u003estate)\n case NR_STATE_2\n nr_state2_machine()\n nr_disconnect()\n nr_sk(sk)-\u003estate = NR_STATE_0\n sock_set_flag(sk, SOCK_DEAD)\n\n nr_heartbeat_expiry\n switch (nr-\u003estate)\n case NR_STATE_0\n if (sock_flag(sk, SOCK_DESTROY) ||\n (sk-\u003esk_state == TCP_LISTEN\n \u0026\u0026 sock_flag(sk, SOCK_DEAD)))\n sock_hold() // ( !!! )\n nr_destroy_socket()\n\nTo fix the memory leak, let's call sock_hold() only for a listening socket.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller.\n\n[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16\n\n * CVE-2024-41007: In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: avoid too many retransmit packets\n\nIf a TCP socket is using TCP_USER_TIMEOUT, and the other peer\nretracted its window to zero, tcp_retransmit_timer() can\nretransmit a packet every two jiffies (2 ms for HZ=1000),\nfor about 4 minutes after TCP_USER_TIMEOUT has 'expired'.\n\nThe fix is to make sure tcp_rtx_probe0_timed_out() takes\nicsk-\u003eicsk_user_timeout into account.\n\nBefore blamed commit, the socket would not timeout after\nicsk-\u003eicsk_user_timeout, but would use standard exponential\nbackoff for the retransmits.\n\nAlso worth noting that before commit e89688e3e978 (\"net: tcp:\nfix unexcepted socket die when snd_wnd is 0\"), the issue\nwould last 2 minutes instead of 4.\n\n * CVE-2024-41011: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: don't allow mapping the MMIO HDP page with large pages\n\nWe don't get the right offset in that case. The GPU has\nan unused 4K area of the register BAR space into which you can\nremap registers. We remap the HDP flush registers into this\nspace to allow userspace (CPU or GPU) to flush the HDP when it\nupdates VRAM. However, on systems with \u003e4K pages, we end up\nexposing PAGE_SIZE of MMIO space.\n\n * CVE-2024-41012: In the Linux kernel, the following vulnerability has been resolved:\n\nfilelock: Remove locks reliably when fcntl/close race is detected\n\nWhen fcntl_setlk() races with close(), it removes the created lock with\ndo_lock_file_wait().\nHowever, LSMs can allow the first do_lock_file_wait() that created the lock\nwhile denying the second do_lock_file_wait() that tries to remove the lock.\nSeparately, posix_lock_file() could also fail to\nremove a lock due to GFP_KERNEL allocation failure (when splitting a range\nin the middle).\n\nAfter the bug has been triggered, use-after-free reads will occur in\nlock_get_status() when userspace reads /proc/locks. This can likely be used\nto read arbitrary kernel memory, but can't corrupt kernel memory.\n\nFix it by calling locks_remove_posix() instead, which is designed to\nreliably get rid of POSIX locks associated with the given file and\nfiles_struct and is also used by filp_flush().\n\n * CVE-2024-41040: In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Fix UAF when resolving a clash\n\nKASAN reports the following UAF:\n\n BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]\n Read of size 1 at addr ffff888c07603600 by task handler130/6469\n\n Call Trace:\n \u003cIRQ\u003e\n dump_stack_lvl+0x48/0x70\n print_address_description.constprop.0+0x33/0x3d0\n print_report+0xc0/0x2b0\n kasan_report+0xd0/0x120\n __asan_load1+0x6c/0x80\n tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]\n tcf_ct_act+0x886/0x1350 [act_ct]\n tcf_action_exec+0xf8/0x1f0\n fl_classify+0x355/0x360 [cls_flower]\n __tcf_classify+0x1fd/0x330\n tcf_classify+0x21c/0x3c0\n sch_handle_ingress.constprop.0+0x2c5/0x500\n __netif_receive_skb_core.constprop.0+0xb25/0x1510\n __netif_receive_skb_list_core+0x220/0x4c0\n netif_receive_skb_list_internal+0x446/0x620\n napi_complete_done+0x157/0x3d0\n gro_cell_poll+0xcf/0x100\n __napi_poll+0x65/0x310\n net_rx_action+0x30c/0x5c0\n __do_softirq+0x14f/0x491\n __irq_exit_rcu+0x82/0xc0\n irq_exit_rcu+0xe/0x20\n common_interrupt+0xa1/0xb0\n \u003c/IRQ\u003e\n \u003cTASK\u003e\n asm_common_interrupt+0x27/0x40\n\n Allocated by task 6469:\n kasan_save_stack+0x38/0x70\n kasan_set_track+0x25/0x40\n kasan_save_alloc_info+0x1e/0x40\n __kasan_krealloc+0x133/0x190\n krealloc+0xaa/0x130\n nf_ct_ext_add+0xed/0x230 [nf_conntrack]\n tcf_ct_act+0x1095/0x1350 [act_ct]\n tcf_action_exec+0xf8/0x1f0\n fl_classify+0x355/0x360 [cls_flower]\n __tcf_classify+0x1fd/0x330\n tcf_classify+0x21c/0x3c0\n sch_handle_ingress.constprop.0+0x2c5/0x500\n __netif_receive_skb_core.constprop.0+0xb25/0x1510\n __netif_receive_skb_list_core+0x220/0x4c0\n netif_receive_skb_list_internal+0x446/0x620\n napi_complete_done+0x157/0x3d0\n gro_cell_poll+0xcf/0x100\n __napi_poll+0x65/0x310\n net_rx_action+0x30c/0x5c0\n __do_softirq+0x14f/0x491\n\n Freed by task 6469:\n kasan_save_stack+0x38/0x70\n kasan_set_track+0x25/0x40\n kasan_save_free_info+0x2b/0x60\n ____kasan_slab_free+0x180/0x1f0\n __kasan_slab_free+0x12/0x30\n slab_free_freelist_hook+0xd2/0x1a0\n __kmem_cache_free+0x1a2/0x2f0\n kfree+0x78/0x120\n nf_conntrack_free+0x74/0x130 [nf_conntrack]\n nf_ct_destroy+0xb2/0x140 [nf_conntrack]\n __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]\n nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]\n __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]\n tcf_ct_act+0x12ad/0x1350 [act_ct]\n tcf_action_exec+0xf8/0x1f0\n fl_classify+0x355/0x360 [cls_flower]\n __tcf_classify+0x1fd/0x330\n tcf_classify+0x21c/0x3c0\n sch_handle_ingress.constprop.0+0x2c5/0x500\n __netif_receive_skb_core.constprop.0+0xb25/0x1510\n __netif_receive_skb_list_core+0x220/0x4c0\n netif_receive_skb_list_internal+0x446/0x620\n napi_complete_done+0x157/0x3d0\n gro_cell_poll+0xcf/0x100\n __napi_poll+0x65/0x310\n net_rx_action+0x30c/0x5c0\n __do_softirq+0x14f/0x491\n\nThe ct may be dropped if a clash has been resolved but is still passed to\nthe tcf_ct_flow_table_process_conn function for further usage. This issue\ncan be fixed by retrieving ct from skb again after confirming conntrack.\n\n * CVE-2024-41046: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: lantiq_etop: fix double free in detach\n\nThe number of the currently released descriptor is never incremented\nwhich results in the same skb being released multiple times.\n\n * CVE-2024-41049: In the Linux kernel, the following vulnerability has been resolved:\n\nfilelock: fix potential use-after-free in posix_lock_inode\n\nLight Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().\nThe request pointer had been changed earlier to point to a lock entry\nthat was added to the inode's list. However, before the tracepoint could\nfire, another task raced in and freed that lock.\n\nFix this by moving the tracepoint inside the spinlock, which should\nensure that this doesn't happen.\n\n * CVE-2024-41055: In the Linux kernel, the following vulnerability has been resolved:\n\nmm: prevent derefencing NULL ptr in pfn_section_valid()\n\nCommit 5ec8e8ea8b77 (\"mm/sparsemem: fix race in accessing\nmemory_section-\u003eusage\") changed pfn_section_valid() to add a READ_ONCE()\ncall around \"ms-\u003eusage\" to fix a race with section_deactivate() where\nms-\u003eusage can be cleared. The READ_ONCE() call, by itself, is not enough\nto prevent NULL pointer dereference. We need to check its value before\ndereferencing it.\n\n * CVE-2024-41059: In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix uninit-value in copy_name\n\n[syzbot reported]\nBUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160\n sized_strscpy+0xc4/0x160\n copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411\n hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3877 [inline]\n slab_alloc_node mm/slub.c:3918 [inline]\n kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065\n kmalloc include/linux/slab.h:628 [inline]\n hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[Fix]\nWhen allocating memory to strbuf, initialize memory to 0.\n\n * CVE-2024-41063: In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: cancel all works upon hci_unregister_dev()\n\nsyzbot is reporting that calling hci_release_dev() from hci_error_reset()\ndue to hci_dev_put() from hci_error_reset() can cause deadlock at\ndestroy_workqueue(), for hci_error_reset() is called from\nhdev-\u003ereq_workqueue which destroy_workqueue() needs to flush.\n\nWe need to make sure that hdev-\u003e{rx_work,cmd_work,tx_work} which are\nqueued into hdev-\u003eworkqueue and hdev-\u003e{power_on,error_reset} which are\nqueued into hdev-\u003ereq_workqueue are no longer running by the moment\n\n destroy_workqueue(hdev-\u003eworkqueue);\n destroy_workqueue(hdev-\u003ereq_workqueue);\n\nare called from hci_release_dev().\n\nCall cancel_work_sync() on these work items from hci_unregister_dev()\nas soon as hdev-\u003elist is removed from hci_dev_list.\n\n * CVE-2024-41064: In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/eeh: avoid possible crash when edev-\u003epdev changes\n\nIf a PCI device is removed during eeh_pe_report_edev(), edev-\u003epdev\nwill change and can cause a crash, hold the PCI rescan/remove lock\nwhile taking a copy of edev-\u003epdev-\u003ebus.\n\n * CVE-2024-41070: In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()\n\nAl reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().\n\nIt looks up `stt` from tablefd, but then continues to use it after doing\nfdput() on the returned fd. After the fdput() the tablefd is free to be\nclosed by another thread. The close calls kvm_spapr_tce_release() and\nthen release_spapr_tce_table() (via call_rcu()) which frees `stt`.\n\nAlthough there are calls to rcu_read_lock() in\nkvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent\nthe UAF, because `stt` is used outside the locked regions.\n\nWith an artifcial delay after the fdput() and a userspace program which\ntriggers the race, KASAN detects the UAF:\n\n BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505\n CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1\n Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV\n Call Trace:\n dump_stack_lvl+0xb4/0x108 (unreliable)\n print_report+0x2b4/0x6ec\n kasan_report+0x118/0x2b0\n __asan_load4+0xb8/0xd0\n kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n kvm_vfio_set_attr+0x524/0xac0 [kvm]\n kvm_device_ioctl+0x144/0x240 [kvm]\n sys_ioctl+0x62c/0x1810\n system_call_exception+0x190/0x440\n system_call_vectored_common+0x15c/0x2ec\n ...\n Freed by task 0:\n ...\n kfree+0xec/0x3e0\n release_spapr_tce_table+0xd4/0x11c [kvm]\n rcu_core+0x568/0x16a0\n handle_softirqs+0x23c/0x920\n do_softirq_own_stack+0x6c/0x90\n do_softirq_own_stack+0x58/0x90\n __irq_exit_rcu+0x218/0x2d0\n irq_exit+0x30/0x80\n arch_local_irq_restore+0x128/0x230\n arch_local_irq_enable+0x1c/0x30\n cpuidle_enter_state+0x134/0x5cc\n cpuidle_enter+0x6c/0xb0\n call_cpuidle+0x7c/0x100\n do_idle+0x394/0x410\n cpu_startup_entry+0x60/0x70\n start_secondary+0x3fc/0x410\n start_secondary_prolog+0x10/0x14\n\nFix it by delaying the fdput() until `stt` is no longer in use, which\nis effectively the entire function. To keep the patch minimal add a call\nto fdput() at each of the existing return paths. Future work can convert\nthe function to goto or __cleanup style cleanup.\n\nWith the fix in place the test case no longer triggers the UAF.\n\n * CVE-2024-41087: In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-core: Fix double free on error\n\nIf e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump\nto the err_out label, which will call devres_release_group().\ndevres_release_group() will trigger a call to ata_host_release().\nata_host_release() calls kfree(host), so executing the kfree(host) in\nata_host_alloc() will lead to a double free:\n\nkernel BUG at mm/slub.c:553!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:kfree+0x2cf/0x2f0\nCode: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da\nRSP: 0018:ffffc90000f377f0 EFLAGS: 00010246\nRAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320\nRDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0\nRBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780\nR13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006\nFS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u003cTASK\u003e\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x6a/0x90\n ? kfree+0x2cf/0x2f0\n ? exc_invalid_op+0x50/0x70\n ? kfree+0x2cf/0x2f0\n ? asm_exc_invalid_op+0x1a/0x20\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? kfree+0x2cf/0x2f0\n ata_host_alloc+0xf5/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\n\nEnsure that we will not call kfree(host) twice, by performing the kfree()\nonly if the devres_open_group() call failed.\n\n * CVE-2024-41089: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes\n\nIn nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().\nAdd a check to avoid null pointer dereference.\n\n * CVE-2024-41092: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: Fix potential UAF by revoke of fence registers\n\nCI has been sporadically reporting the following issue triggered by\nigt@i915_selftest@live@hangcheck on ADL-P and similar machines:\n\n\u003c6\u003e [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence\n...\n\u003c6\u003e [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled\n\u003c6\u003e [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled\n\u003c3\u003e [414.070354] Unable to pin Y-tiled fence; err:-4\n\u003c3\u003e [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(\u0026fence-\u003eactive))\n...\n\u003c4\u003e[ 609.603992] ------------[ cut here ]------------\n\u003c2\u003e[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!\n\u003c4\u003e[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n\u003c4\u003e[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1\n\u003c4\u003e[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023\n\u003c4\u003e[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]\n\u003c4\u003e[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]\n...\n\u003c4\u003e[ 609.604271] Call Trace:\n\u003c4\u003e[ 609.604273] \u003cTASK\u003e\n...\n\u003c4\u003e[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]\n\u003c4\u003e[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]\n\u003c4\u003e[ 609.604977] force_unbind+0x24/0xa0 [i915]\n\u003c4\u003e[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]\n\u003c4\u003e[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]\n\u003c4\u003e[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]\n\u003c4\u003e[ 609.605440] process_scheduled_works+0x351/0x690\n...\n\nIn the past, there were similar failures reported by CI from other IGT\ntests, observed on other platforms.\n\nBefore commit 63baf4f3d587 (\"drm/i915/gt: Only wait for GPU activity\nbefore unbinding a GGTT fence\"), i915_vma_revoke_fence() was waiting for\nidleness of vma-\u003eactive via fence_update(). That commit introduced\nvma-\u003efence-\u003eactive in order for the fence_update() to be able to wait\nselectively on that one instead of vma-\u003eactive since only idleness of\nfence registers was needed. But then, another commit 0d86ee35097a\n(\"drm/i915/gt: Make fence revocation unequivocal\") replaced the call to\nfence_update() in i915_vma_revoke_fence() with only fence_write(), and\nalso added that GEM_BUG_ON(!i915_active_is_idle(\u0026fence-\u003eactive)) in front.\nNo justification was provided on why we might then expect idleness of\nvma-\u003efence-\u003eactive without first waiting on it.\n\nThe issue can be potentially caused by a race among revocation of fence\nregisters on one side and sequential execution of signal callbacks invoked\non completion of a request that was using them on the other, still\nprocessed in parallel to revocation of those fence registers. Fix it by\nwaiting for idleness of vma-\u003efence-\u003eactive in i915_vma_revoke_fence().\n\n(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)\n\n * CVE-2024-41095: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes\n\nIn nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.\n\n * CVE-2024-41097: In the Linux kernel, the following vulnerability has been resolved:\n\nusb: atm: cxacru: fix endpoint checking in cxacru_bind()\n\nSyzbot is still reporting quite an old issue [1] that occurs due to\nincomplete checking of present usb endpoints. As such, wrong\nendpoints types may be used at urb sumbitting stage which in turn\ntriggers a warning in usb_submit_urb().\n\nFix the issue by verifying that required endpoint types are present\nfor both in and out endpoints, taking into account cmd endpoint type.\n\nUnfortunately, this patch has not been tested on real hardware.\n\n[1] Syzbot report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\nModules linked in:\nCPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\n...\nCall Trace:\n cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649\n cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760\n cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209\n usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055\n cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363\n usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:517 [inline]\n really_probe+0x23c/0xcd0 drivers/base/dd.c:595\n __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777\n __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894\n bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427\n __device_attach+0x228/0x4a0 drivers/base/dd.c:965\n bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487\n device_add+0xc2f/0x2180 drivers/base/core.c:3354\n usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293\n\n * CVE-2024-42070: In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers\n\nregister store validation for NFT_DATA_VALUE is conditional, however,\nthe datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This\nonly requires a new helper function to infer the register type from the\nset datatype so this conditional check can be removed. Otherwise,\npointer to chain object can be leaked through the registers.\n\n * CVE-2024-42076: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: can: j1939: Initialize unused data in j1939_send_one()\n\nsyzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()\ncreates full frame including unused data, but it doesn't initialize\nit. This causes the kernel-infoleak issue. Fix this by initializing\nunused data.\n\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n copy_to_user_iter lib/iov_iter.c:24 [inline]\n iterate_ubuf include/linux/iov_iter.h:29 [inline]\n iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n iterate_and_advance include/linux/iov_iter.h:271 [inline]\n _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n copy_to_iter include/linux/uio.h:196 [inline]\n memcpy_to_msg include/linux/skbuff.h:4113 [inline]\n raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x2c4/0x340 net/socket.c:1068\n ____sys_recvmsg+0x18a/0x620 net/socket.c:2803\n ___sys_recvmsg+0x223/0x840 net/socket.c:2845\n do_recvmmsg+0x4fc/0xfd0 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+0x397/0x490 net/socket.c:3034\n x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3804 [inline]\n slab_alloc_node mm/slub.c:3845 [inline]\n kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n alloc_skb include/linux/skbuff.h:1313 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n sock_alloc_send_skb include/net/sock.h:1842 [inline]\n j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]\n j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]\n j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n ____sys_sendmsg+0x877/0xb60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674\n x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nBytes 12-15 of 16 are uninitialized\nMemory access of size 16 starts at ffff888120969690\nData copied to user address 00000000200017c0\n\nCPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n\n * CVE-2024-42077: In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix DIO failure due to insufficient transaction credits\n\nThe code in ocfs2_dio_end_io_write() estimates number of necessary\ntransaction credits using ocfs2_calc_extend_credits(). This however does\nnot take into account that the IO could be arbitrarily large and can\ncontain arbitrary number of extents.\n\nExtent tree manipulations do often extend the current transaction but not\nin all of the cases. For example if we have only single block extents in\nthe tree, ocfs2_mark_extent_written() will end up calling\nocfs2_replace_extent_rec() all the time and we will never extend the\ncurrent transaction and eventually exhaust all the transaction credits if\nthe IO contains many single block extents. Once that happens a\nWARN_ON(jbd2_handle_buffer_credits(handle) \u003c= 0) is triggered in\njbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to\nthis error. This was actually triggered by one of our customers on a\nheavily fragmented OCFS2 filesystem.\n\nTo fix the issue make sure the transaction always has enough credits for\none extent insert before each call of ocfs2_mark_extent_written().\n\nHeming Zhao said:\n\n------\nPANIC: \"Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error\"\n\nPID: xxx TASK: xxxx CPU: 5 COMMAND: \"SubmitThread-CA\"\n #0 machine_kexec at ffffffff8c069932\n #1 __crash_kexec at ffffffff8c1338fa\n #2 panic at ffffffff8c1d69b9\n #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]\n #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]\n #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]\n #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]\n #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]\n #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]\n #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]\n#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]\n#11 dio_complete at ffffffff8c2b9fa7\n#12 do_blockdev_direct_IO at ffffffff8c2bc09f\n#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]\n#14 generic_file_direct_write at ffffffff8c1dcf14\n#15 __generic_file_write_iter at ffffffff8c1dd07b\n#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]\n#17 aio_write at ffffffff8c2cc72e\n#18 kmem_cache_alloc at ffffffff8c248dde\n#19 do_io_submit at ffffffff8c2ccada\n#20 do_syscall_64 at ffffffff8c004984\n#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba\n\n * CVE-2024-42082: In the Linux kernel, the following vulnerability has been resolved:\n\nxdp: Remove WARN() from __xdp_reg_mem_model()\n\nsyzkaller reports a warning in __xdp_reg_mem_model().\n\nThe warning occurs only if __mem_id_init_hash_table() returns an error. It\nreturns the error in two cases:\n\n 1. memory allocation fails;\n 2. rhashtable_init() fails when some fields of rhashtable_params\n struct are not initialized properly.\n\nThe second case cannot happen since there is a static const rhashtable_params\nstruct with valid fields. So, warning is only triggered when there is a\nproblem with memory allocation.\n\nThus, there is no sense in using WARN() to handle this error and it can be\nsafely removed.\n\nWARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299\n\nCPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299\n\nCall Trace:\n xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344\n xdp_test_run_setup net/bpf/test_run.c:188 [inline]\n bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377\n bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267\n bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240\n __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649\n __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nFound by Linux Verification Center (linuxtesting.org) with syzkaller.\n\n * CVE-2024-42090: In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER\n\nIn create_pinctrl(), pinctrl_maps_mutex is acquired before calling\nadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()\ncalls pinctrl_free(). However, pinctrl_free() attempts to acquire\npinctrl_maps_mutex, which is already held by create_pinctrl(), leading to\na potential deadlock.\n\nThis patch resolves the issue by releasing pinctrl_maps_mutex before\ncalling pinctrl_free(), preventing the deadlock.\n\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.\n\n * CVE-2024-42093: In the Linux kernel, the following vulnerability has been resolved:\n\nnet/dpaa2: Avoid explicit cpumask var allocation on stack\n\nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask\nvariable on stack is not recommended since it can cause potential stack\noverflow.\n\nInstead, kernel code should always use *cpumask_var API(s) to allocate\ncpumask var in config-neutral way, leaving allocation strategy to\nCONFIG_CPUMASK_OFFSTACK.\n\nUse *cpumask_var API(s) to address it.\n\n * CVE-2024-42094: In the Linux kernel, the following vulnerability has been resolved:\n\nnet/iucv: Avoid explicit cpumask var allocation on stack\n\nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask\nvariable on stack is not recommended since it can cause potential stack\noverflow.\n\nInstead, kernel code should always use *cpumask_var API(s) to allocate\ncpumask var in config-neutral way, leaving allocation strategy to\nCONFIG_CPUMASK_OFFSTACK.\n\nUse *cpumask_var API(s) to address it.\n\n * CVE-2024-42101: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix null pointer dereference in nouveau_connector_get_modes\n\nIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.\n\n * CVE-2024-42102: In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again\"\n\nPatch series \"mm: Avoid possible overflows in dirty throttling\".\n\nDirty throttling logic assumes dirty limits in page units fit into\n32-bits. This patch series makes sure this is true (see patch 2/2 for\nmore details).\n\n\nThis patch (of 2):\n\nThis reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.\n\nThe commit is broken in several ways. Firstly, the removed (u64) cast\nfrom the multiplication will introduce a multiplication overflow on 32-bit\narchs if wb_thresh * bg_thresh \u003e= 1\u003c\u003c32 (which is actually common - the\ndefault settings with 4GB of RAM will trigger this). Secondly, the\ndiv64_u64() is unnecessarily expensive on 32-bit archs. We have\ndiv64_ul() in case we want to be safe \u0026 cheap. Thirdly, if dirty\nthresholds are larger than 1\u003c\u003c32 pages, then dirty balancing is going to\nblow up in many other spectacular ways anyway so trying to fix one\npossible overflow is just moot.\n\n * CVE-2024-42104: In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: add missing check for inode numbers on directory entries\n\nSyzbot reported that mounting and unmounting a specific pattern of\ncorrupted nilfs2 filesystem images causes a use-after-free of metadata\nfile inodes, which triggers a kernel bug in lru_add_fn().\n\nAs Jan Kara pointed out, this is because the link count of a metadata file\ngets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),\ntries to delete that inode (ifile inode in this case).\n\nThe inconsistency occurs because directories containing the inode numbers\nof these metadata files that should not be visible in the namespace are\nread without checking.\n\nFix this issue by treating the inode numbers of these internal files as\nerrors in the sanity check helper when reading directory folios/pages.\n\nAlso thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer\nanalysis.\n\n * CVE-2024-42131: In the Linux kernel, the following vulnerability has been resolved:\n\nmm: avoid overflows in dirty throttling logic\n\nThe dirty throttling logic is interspersed with assumptions that dirty\nlimits in PAGE_SIZE units fit into 32-bit (so that various multiplications\nfit into 64-bits). If limits end up being larger, we will hit overflows,\npossible divisions by 0 etc. Fix these problems by never allowing so\nlarge dirty limits as they have dubious practical value anyway. For\ndirty_bytes / dirty_background_bytes interfaces we can just refuse to set\nso large limits. For dirty_ratio / dirty_background_ratio it isn't so\nsimple as the dirty limit is computed from the amount of available memory\nwhich can change due to memory hotplug etc. So when converting dirty\nlimits from ratios to numbers of pages, we just don't allow the result to\nexceed UINT_MAX.\n\nThis is root-only triggerable problem which occurs when the operator\nsets dirty limits to \u003e16 TB.\n\n * CVE-2024-42137: In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot\n\nCommit 272970be3dab (\"Bluetooth: hci_qca: Fix driver shutdown on closed\nserdev\") will cause below regression issue:\n\nBT can't be enabled after below steps:\ncold boot -\u003e enable BT -\u003e disable BT -\u003e warm reboot -\u003e BT enable failure\nif property enable-gpios is not configured within DT|ACPI for QCA6390.\n\nThe commit is to fix a use-after-free issue within qca_serdev_shutdown()\nby adding condition to avoid the serdev is flushed or wrote after closed\nbut also introduces this regression issue regarding above steps since the\nVSC is not sent to reset controller during warm reboot.\n\nFixed by sending the VSC to reset controller within qca_serdev_shutdown()\nonce BT was ever enabled, and the use-after-free issue is also fixed by\nthis change since the serdev is still opened before it is flushed or wrote.\n\nVerified by the reported machine Dell XPS 13 9310 laptop over below two\nkernel commits:\ncommit e00fc2700a3f (\"Bluetooth: btusb: Fix triggering coredump\nimplementation for QCA\") of bluetooth-next tree.\ncommit b23d98d46d28 (\"Bluetooth: btusb: Fix triggering coredump\nimplementation for QCA\") of linus mainline tree.\n\n * CVE-2024-42148: In the Linux kernel, the following vulnerability has been resolved:\n\nbnx2x: Fix multiple UBSAN array-index-out-of-bounds\n\nFix UBSAN warnings that occur when using a system with 32 physical\ncpu cores or more, or when the user defines a number of Ethernet\nqueues greater than or equal to FP_SB_MAX_E1x using the num_queues\nmodule parameter.\n\nCurrently there is a read/write out of bounds that occurs on the array\n\"struct stats_query_entry query\" present inside the \"bnx2x_fw_stats_req\"\nstruct in \"drivers/net/ethernet/broadcom/bnx2x/bnx2x.h\".\nLooking at the definition of the \"struct stats_query_entry query\" array:\n\nstruct stats_query_entry query[FP_SB_MAX_E1x+\n BNX2X_FIRST_QUEUE_QUERY_IDX];\n\nFP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and\nhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3\nmeaning the array has a total size of 19.\nSince accesses to \"struct stats_query_entry query\" are offset-ted by\nBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet\nqueues should not exceed FP_SB_MAX_E1x (16). However one of these queues\nis reserved for FCOE and thus the number of Ethernet queues should be set\nto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if\nit is not.\n\nThis is also described in a comment in the source code in\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition\nof FP_SB_MAX_E1x. Below is the part of this explanation that it important\nfor this patch\n\n/*\n * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is\n * control by the number of fast-path status blocks supported by the\n * device (HW/FW). Each fast-path status block (FP-SB) aka non-default\n * status block represents an independent interrupts context that can\n * serve a regular L2 networking queue. However special L2 queues such\n * as the FCoE queue do not require a FP-SB and other components like\n * the CNIC may consume FP-SB reducing the number of possible L2 queues\n *\n * If the maximum number of FP-SB available is X then:\n * a. If CNIC is supported it consumes 1 FP-SB thus the max number of\n * regular L2 queues is Y=X-1\n * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)\n * c. If the FCoE L2 queue is supported the actual number of L2 queues\n * is Y+1\n * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for\n * slow-path interrupts) or Y+2 if CNIC is supported (one additional\n * FP interrupt context for the CNIC).\n * e. The number of HW context (CID count) is always X or X+1 if FCoE\n * L2 queue is supported. The cid for the FCoE L2 queue is always X.\n */\n\nHowever this driver also supports NICs that use the E2 controller which can\nhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.\nLooking at the commits when the E2 support was added, it was originally\nusing the E1x parameters: commit f2e0899f0f27 (\"bnx2x: Add 57712 support\").\nBack then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver\nwas later updated to take full advantage of the E2 instead of having it be\nlimited to the capabilities of the E1x. But as far as we can tell, the\narray \"stats_query_entry query\" was still limited to using the FP-SB\navailable to the E1x cards as part of an oversignt when the driver was\nupdated to take full advantage of the E2, and now with the driver being\naware of the greater queue size supported by E2 NICs, it causes the UBSAN\nwarnings seen in the stack traces below.\n\nThis patch increases the size of the \"stats_query_entry query\" array by\nreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle\nboth types of NICs.\n\nStack traces:\n\nUBSAN: array-index-out-of-bounds in\n drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11\nindex 20 is out of range for type 'stats_query_entry [19]'\nCPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic\n\t #202405052133\nHardware name: HP ProLiant DL360 Gen9/ProLiant DL360 \n---truncated---\n\n * CVE-2024-42152: In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\n\nIn nvmet_sq_destroy we capture sq-\u003ectrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u003esqs and sq-\u003ectrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\n\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u003eref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u003ectrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\n\nSolve this by re-capturing the sq-\u003ectrl after all inflight request has\ncompleted, where for sure sq-\u003ectrl reference is final, and move forward\nbased on that.\n\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.\n\n * CVE-2024-42153: In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\n\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.\n\n * CVE-2024-42154: In the Linux kernel, the following vulnerability has been resolved:\n\ntcp_metrics: validate source addr length\n\nI don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4\nis at least 4 bytes long, and the policy doesn't have an entry\nfor this attribute at all (neither does it for IPv6 but v6 is\nmanually validated).\n\n * CVE-2024-42157: In the Linux kernel, the following vulnerability has been resolved:\n\ns390/pkey: Wipe sensitive data on failure\n\nWipe sensitive data from stack also if the copy_to_user() fails.\n\n * CVE-2024-42161: In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD\n\n[Changes from V1:\n - Use a default branch in the switch statement to initialize `val'.]\n\nGCC warns that `val' may be used uninitialized in the\nBPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:\n\n\t[...]\n\tunsigned long long val;\t\t\t\t\t\t \\\n\t[...]\t\t\t\t\t\t\t\t \\\n\tswitch (__CORE_RELO(s, field, BYTE_SIZE)) {\t\t\t \\\n\tcase 1: val = *(const unsigned char *)p; break;\t\t\t \\\n\tcase 2: val = *(const unsigned short *)p; break;\t\t \\\n\tcase 4: val = *(const unsigned int *)p; break;\t\t\t \\\n\tcase 8: val = *(const unsigned long long *)p; break;\t\t \\\n } \t\t\t\t\t\t\t \\\n\t[...]\n\tval;\t\t\t\t\t\t\t\t \\\n\t}\t\t\t\t\t\t\t\t \\\n\nThis patch adds a default entry in the switch statement that sets\n`val' to zero in order to avoid the warning, and random values to be\nused in case __builtin_preserve_field_info returns unexpected values\nfor BPF_FIELD_BYTE_SIZE.\n\nTested in bpf-next master.\nNo regressions.\n\n * CVE-2024-42223: In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-frontends: tda10048: Fix integer overflow\n\nstate-\u003extal_hz can be up to 16M, so it can overflow a 32 bit integer\nwhen multiplied by pll_mfactor.\n\nCreate a new 64 bit variable to hold the calculations.\n\n * CVE-2024-42224: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: mv88e6xxx: Correct check for empty list\n\nSince commit a3c53be55c95 (\"net: dsa: mv88e6xxx: Support multiple MDIO\nbusses\") mv88e6xxx_default_mdio_bus() has checked that the\nreturn value of list_first_entry() is non-NULL.\n\nThis appears to be intended to guard against the list chip-\u003emdios being\nempty. However, it is not the correct check as the implementation of\nlist_first_entry is not designed to return NULL for empty lists.\n\nInstead, use list_first_entry_or_null() which does return NULL if the\nlist is empty.\n\nFlagged by Smatch.\nCompile tested only.\n\n * CVE-2024-42229: In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: aead,cipher - zeroize key buffer after use\n\nI.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding\ncryptographic information should be zeroized once they are no longer\nneeded. Accomplish this by using kfree_sensitive for buffers that\npreviously held the private key.\n\n * CVE-2024-42232: In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix race between delayed_work() and ceph_monc_stop()\n\nThe way the delayed work is handled in ceph_monc_stop() is prone to\nraces with mon_fault() and possibly also finish_hunting(). Both of\nthese can requeue the delayed work which wouldn't be canceled by any of\nthe following code in case that happens after cancel_delayed_work_sync()\nruns -- __close_session() doesn't mess with the delayed work in order\nto avoid interfering with the hunting interval logic. This part was\nmissed in commit b5d91704f53e (\"libceph: behave in mon_fault() if\ncur_mon \u003c 0\") and use-after-free can still ensue on monc and objects\nthat hang off of it, with monc-\u003eauth and monc-\u003emonmap being\nparticularly susceptible to quickly being reused.\n\nTo fix this:\n\n- clear monc-\u003ecur_mon and monc-\u003ehunting as part of closing the session\n in ceph_monc_stop()\n- bail from delayed_work() if monc-\u003ecur_mon is cleared, similar to how\n it's done in mon_fault() and finish_hunting() (based on monc-\u003ehunting)\n- call cancel_delayed_work_sync() after the session is closed\n\n * CVE-2024-42236: In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: configfs: Prevent OOB read/write in usb_string_copy()\n\nUserspace provided string 's' could trivially have the length zero. Left\nunchecked this will firstly result in an OOB read in the form\n`if (str[0 - 1] == '\\n') followed closely by an OOB write in the form\n`str[0 - 1] = '\\0'`.\n\nThere is already a validating check to catch strings that are too long.\nLet's supply an additional check for invalid strings that are too short.\n\n * CVE-2024-42244: In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mos7840: fix crash on resume\n\nSince commit c49cfa917025 (\"USB: serial: use generic method if no\nalternative is provided in usb serial layer\"), USB serial core calls the\ngeneric resume implementation when the driver has not provided one.\n\nThis can trigger a crash on resume with mos7840 since support for\nmultiple read URBs was added back in 2011. Specifically, both port read\nURBs are now submitted on resume for open ports, but the context pointer\nof the second URB is left set to the core rather than mos7840 port\nstructure.\n\nFix this by implementing dedicated suspend and resume functions for\nmos7840.\n\nTested with Delock 87414 USB 2.0 to 4x serial adapter.\n\n[ johan: analyse crash and rewrite commit message; set busy flag on\n resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]\n\n * CVE-2024-42247: In the Linux kernel, the following vulnerability has been resolved:\n\nwireguard: allowedips: avoid unaligned 64-bit memory accesses\n\nOn the parisc platform, the kernel issues kernel warnings because\nswap_endian() tries to load a 128-bit IPv6 address from an unaligned\nmemory location:\n\n Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)\n Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)\n\nAvoid such unaligned memory accesses by instead using the\nget_unaligned_be64() helper macro.\n\n[Jason: replace src[8] in original patch with src+8]\n\n * CVE-2024-42259: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gem: Fix Virtual Memory mapping boundaries calculation\n\nCalculating the size of the mapped area as the lesser value\nbetween the requested size and the actual size does not consider\nthe partial mapping offset. This can cause page fault access.\n\nFix the calculation of the starting and ending addresses, the\ntotal size is now deduced from the difference between the end and\nstart addresses.\n\nAdditionally, the calculations have been rewritten in a clearer\nand more understandable form.\n\n[Joonas: Add Requires: tag]\nRequires: 60a2066c5005 (\"drm/i915/gem: Adjust vma offset for framebuffer mmap offset\")\n(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)\n\n * CVE-2024-42271: In the Linux kernel, the following vulnerability has been resolved:\n\nnet/iucv: fix use after free in iucv_sock_close()\n\niucv_sever_path() is called from process context and from bh context.\niucv-\u003epath is used as indicator whether somebody else is taking care of\nsevering the path (or it is already removed / never existed).\nThis needs to be done with atomic compare and swap, otherwise there is a\nsmall window where iucv_sock_close() will try to work with a path that has\nalready been severed and freed by iucv_callback_connrej() called by\niucv_tasklet_fn().\n\nExample:\n[452744.123844] Call Trace:\n[452744.123845] ([\u003c0000001e87f03880\u003e] 0x1e87f03880)\n[452744.123966] [\u003c00000000d593001e\u003e] iucv_path_sever+0x96/0x138\n[452744.124330] [\u003c000003ff801ddbca\u003e] iucv_sever_path+0xc2/0xd0 [af_iucv]\n[452744.124336] [\u003c000003ff801e01b6\u003e] iucv_sock_close+0xa6/0x310 [af_iucv]\n[452744.124341] [\u003c000003ff801e08cc\u003e] iucv_sock_release+0x3c/0xd0 [af_iucv]\n[452744.124345] [\u003c00000000d574794e\u003e] __sock_release+0x5e/0xe8\n[452744.124815] [\u003c00000000d5747a0c\u003e] sock_close+0x34/0x48\n[452744.124820] [\u003c00000000d5421642\u003e] __fput+0xba/0x268\n[452744.124826] [\u003c00000000d51b382c\u003e] task_work_run+0xbc/0xf0\n[452744.124832] [\u003c00000000d5145710\u003e] do_notify_resume+0x88/0x90\n[452744.124841] [\u003c00000000d5978096\u003e] system_call+0xe2/0x2c8\n[452744.125319] Last Breaking-Event-Address:\n[452744.125321] [\u003c00000000d5930018\u003e] iucv_path_sever+0x90/0x138\n[452744.125324]\n[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt\n\nNote that bh_lock_sock() is not serializing the tasklet context against\nprocess context, because the check for sock_owned_by_user() and\ncorresponding handling is missing.\n\nIdeas for a future clean-up patch:\nA) Correct usage of bh_lock_sock() in tasklet context, as described in\nRe-enqueue, if needed. This may require adding return values to the\ntasklet functions and thus changes to all users of iucv.\n\nB) Change iucv tasklet into worker and use only lock_sock() in af_iucv.\n\n * CVE-2024-42280: In the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: Fix a use after free in hfcmulti_tx()\n\nDon't dereference *sp after calling dev_kfree_skb(*sp).\n\n * CVE-2024-42283: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nexthop: Initialize all fields in dumped nexthops\n\nstruct nexthop_grp contains two reserved fields that are not initialized by\nnla_put_nh_group(), and carry garbage. This can be observed e.g. with\nstrace (edited for clarity):\n\n # ip nexthop add id 1 dev lo\n # ip nexthop add id 101 group 1\n # strace -e recvmsg ip nexthop get id 101\n ...\n recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},\n [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52\n\nThe fields are reserved and therefore not currently used. But as they are, they\nleak kernel memory, and the fact they are not just zero complicates repurposing\nof the fields for new ends. Initialize the full structure.\n\n * CVE-2024-42284: In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Return non-zero value from tipc_udp_addr2str() on error\n\ntipc_udp_addr2str() should return non-zero value if the UDP media\naddress is invalid. Otherwise, a buffer overflow access can occur in\ntipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP\nmedia address.\n\n * CVE-2024-42285: In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/iwcm: Fix a use-after-free related to destroying CM IDs\n\niw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with\nan existing struct iw_cm_id (cm_id) as follows:\n\n conn_id-\u003ecm_id.iw = cm_id;\n cm_id-\u003econtext = conn_id;\n cm_id-\u003ecm_handler = cma_iw_handler;\n\nrdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make\nsure that cm_work_handler() does not trigger a use-after-free by only\nfreeing of the struct rdma_id_private after all pending work has finished.\n\n * CVE-2024-42286: In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: validate nvme_local_port correctly\n\nThe driver load failed with error message,\n\nqla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef\n\nand with a kernel crash,\n\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000070\n\tWorkqueue: events_unbound qla_register_fcport_fn [qla2xxx]\n\tRIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]\n\tRSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282\n\tRAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000\n\tRDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000\n\tRBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030\n\tR10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4\n\tR13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8\n\tFS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000\n\tCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\tCR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0\n\tCall Trace:\n\tqla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]\n\t? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]\n\tqla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]\n\tqla_register_fcport_fn+0x54/0xc0 [qla2xxx]\n\nExit the qla_nvme_register_remote() function when qla_nvme_register_hba()\nfails and correctly validate nvme_local_port.\n\n * CVE-2024-42287: In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Complete command early within lock\n\nA crash was observed while performing NPIV and FW reset,\n\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 1 PREEMPT_RT SMP NOPTI\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0\n RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034\n R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000\n FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u003cTASK\u003e\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x16f/0x4a0\n ? do_user_addr_fault+0x174/0x7f0\n ? exc_page_fault+0x69/0x1a0\n ? asm_exc_page_fault+0x22/0x30\n ? dma_direct_unmap_sg+0x51/0x1e0\n ? preempt_count_sub+0x96/0xe0\n qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]\n qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]\n __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]\n\nThe command completion was done early while aborting the commands in driver\nunload path but outside lock to avoid the WARN_ON condition of performing\ndma_free_attr within the lock. However this caused race condition while\ncommand completion via multiple paths causing system crash.\n\nHence complete the command early in unload path but within the lock to\navoid race condition.\n\n * CVE-2024-42288: In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix for possible memory corruption\n\nInit Control Block is dereferenced incorrectly. Correctly dereference ICB\n\n * CVE-2024-42289: In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: During vport delete send async logout explicitly\n\nDuring vport delete, it is observed that during unload we hit a crash\nbecause of stale entries in outstanding command array. For all these stale\nI/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but\nI/Os could not complete while vport delete is in process of deleting.\n\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n Workqueue: qla2xxx_wq qla_do_work [qla2xxx]\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0\n RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8\n R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000\n FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0\n Call Trace:\n \u003cTASK\u003e\n qla2xxx_qpair_sp_free_dma+0x417/0x4e0\n ? qla2xxx_qpair_sp_compl+0x10d/0x1a0\n ? qla2x00_status_entry+0x768/0x2830\n ? newidle_balance+0x2f0/0x430\n ? dequeue_entity+0x100/0x3c0\n ? qla24xx_process_response_queue+0x6a1/0x19e0\n ? __schedule+0x2d5/0x1140\n ? qla_do_work+0x47/0x60\n ? process_one_work+0x267/0x440\n ? process_one_work+0x440/0x440\n ? worker_thread+0x2d/0x3d0\n ? process_one_work+0x440/0x440\n ? kthread+0x156/0x180\n ? set_kthread_struct+0x50/0x50\n ? ret_from_fork+0x22/0x30\n \u003c/TASK\u003e\n\nSend out async logout explicitly for all the ports during vport delete.\n\n * CVE-2024-42301: In the Linux kernel, the following vulnerability has been resolved:\n\ndev/parport: fix the array out-of-bounds risk\n\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\n\nBelow is the stack trace I encountered during the actual issue:\n\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]\n\n * CVE-2024-42302: In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/DPC: Fix use-after-free on concurrent DPC and hot-removal\n\nKeith reports a use-after-free when a DPC event occurs concurrently to\nhot-removal of the same portion of the hierarchy:\n\nThe dpc_handler() awaits readiness of the secondary bus below the\nDownstream Port where the DPC event occurred. To do so, it polls the\nconfig space of the first child device on the secondary bus. If that\nchild device is concurrently removed, accesses to its struct pci_dev\ncause the kernel to oops.\n\nThat's because pci_bridge_wait_for_secondary_bus() neglects to hold a\nreference on the child device. Before v6.3, the function was only\ncalled on resume from system sleep or on runtime resume. Holding a\nreference wasn't necessary back then because the pciehp IRQ thread\ncould never run concurrently. (On resume from system sleep, IRQs are\nnot enabled until after the resume_noirq phase. And runtime resume is\nalways awaited before a PCI device is removed.)\n\nHowever starting with v6.3, pci_bridge_wait_for_secondary_bus() is also\ncalled on a DPC event. Commit 53b54ad074de (\"PCI/DPC: Await readiness\nof secondary bus after reset\"), which introduced that, failed to\nappreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a\nreference on the child device because dpc_handler() and pciehp may\nindeed run concurrently. The commit was backported to v5.10+ stable\nkernels, so that's the oldest one affected.\n\nAdd the missing reference acquisition.\n\nAbridged stack trace:\n\n BUG: unable to handle page fault for address: 00000000091400c0\n CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0\n RIP: pci_bus_read_config_dword+0x17/0x50\n pci_dev_wait()\n pci_bridge_wait_for_secondary_bus()\n dpc_reset_link()\n pcie_do_recovery()\n dpc_handler()\n\n * CVE-2024-42308: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Check for NULL pointer\n\n[why \u0026 how]\nNeed to make sure plane_state is initialized\nbefore accessing its members.\n\n(cherry picked from commit 295d91cbc700651782a60572f83c24861607b648)\n\n * CVE-2024-42309: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes\n\nIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.\n\n * CVE-2024-42310: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes\n\nIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.\n\n * CVE-2024-42311: In the Linux kernel, the following vulnerability has been resolved:\n\nhfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()\n\nSyzbot reports uninitialized value access issue as below:\n\nloop0: detected capacity change from 0 to 64\n=====================================================\nBUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30\n hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30\n d_revalidate fs/namei.c:862 [inline]\n lookup_fast+0x89e/0x8e0 fs/namei.c:1649\n walk_component fs/namei.c:2001 [inline]\n link_path_walk+0x817/0x1480 fs/namei.c:2332\n path_lookupat+0xd9/0x6f0 fs/namei.c:2485\n filename_lookup+0x22e/0x740 fs/namei.c:2515\n user_path_at_empty+0x8b/0x390 fs/namei.c:2924\n user_path_at include/linux/namei.h:57 [inline]\n do_mount fs/namespace.c:3689 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x66b/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nBUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]\nBUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366\n hfs_ext_read_extent fs/hfs/extent.c:196 [inline]\n hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366\n block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271\n hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39\n filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426\n do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553\n do_read_cache_page mm/filemap.c:3595 [inline]\n read_cache_page+0xfb/0x2f0 mm/filemap.c:3604\n read_mapping_page include/linux/pagemap.h:755 [inline]\n hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78\n hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204\n hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406\n mount_bdev+0x628/0x920 fs/super.c:1359\n hfs_mount+0xcd/0xe0 fs/hfs/super.c:456\n legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610\n vfs_get_tree+0xdc/0x5d0 fs/super.c:1489\n do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145\n path_mount+0xf98/0x26a0 fs/namespace.c:3475\n do_mount fs/namespace.c:3488 [inline]\n __do_sys_mount fs/namespace.c:3697 [inline]\n __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674\n __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\nUninit was created at:\n __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2190 [inline]\n allocate_slab mm/slub.c:2354 [inline]\n new_slab+0x2d7/0x1400 mm/slub.c:2407\n ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540\n __slab_alloc mm/slub.c:3625 [inline]\n __slab_alloc_node mm/slub.c:3678 [inline]\n slab_alloc_node mm/slub.c:3850 [inline]\n kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879\n alloc_inode_sb include/linux/fs.h:3018 [inline]\n hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165\n alloc_inode+0x83/0x440 fs/inode.c:260\n new_inode_pseudo fs/inode.c:1005 [inline]\n new_inode+0x38/0x4f0 fs/inode.c:1031\n hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186\n hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228\n vfs_mkdir+0x49a/0x700 fs/namei.c:4126\n do_mkdirat+0x529/0x810 fs/namei.c:4149\n __do_sys_mkdirat fs/namei.c:4164 [inline]\n __se_sys_mkdirat fs/namei.c:4162 [inline]\n __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nIt missed to initialize .tz_secondswest, .cached_start and .cached_blocks\nfields in struct hfs_inode_info after hfs_alloc_inode(), fix it.\n\n * CVE-2024-42313: In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: fix use after free in vdec_close\n\nThere appears to be a possible use after free with vdec_close().\nThe firmware will add buffer release work to the work queue through\nHFI callbacks as a normal part of decoding. Randomly closing the\ndecoder device from userspace during normal decoding can incur\na read after free for inst.\n\nFix it by cancelling the work in vdec_close.\n\n * CVE-2024-43828: In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix infinite loop when replaying fast_commit\n\nWhen doing fast_commit replay an infinite loop may occur due to an\nuninitialized extent_status struct. ext4_ext_determine_insert_hole() does\nnot detect the replay and calls ext4_es_find_extent_range(), which will\nreturn immediately without initializing the 'es' variable.\n\nBecause 'es' contains garbage, an integer overflow may happen causing an\ninfinite loop in this function, easily reproducible using fstest generic/039.\n\nThis commit fixes this issue by unconditionally initializing the structure\nin function ext4_es_find_extent_range().\n\nThanks to Zhang Yi, for figuring out the real problem!\n\n * CVE-2024-43856: In the Linux kernel, the following vulnerability has been resolved:\n\ndma: fix call order in dmam_free_coherent\n\ndmam_free_coherent() frees a DMA allocation, which makes the\nfreed vaddr available for reuse, then calls devres_destroy()\nto remove and free the data structure used to track the DMA\nallocation. Between the two calls, it is possible for a\nconcurrent task to make an allocation with the same vaddr\nand add it to the devres list.\n\nIf this happens, there will be two entries in the devres list\nwith the same vaddr and devres_destroy() can free the wrong\nentry, triggering the WARN_ON() in dmam_match.\n\nFix by destroying the devres entry before freeing the DMA\nallocation.\n\n kokonut //net/encryption\n http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03\n\n * CVE-2024-43858: In the Linux kernel, the following vulnerability has been resolved:\n\njfs: Fix array-index-out-of-bounds in diFree\n\n * CVE-2024-43860: In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: imx_rproc: Skip over memory region when node value is NULL\n\nIn imx_rproc_addr_init() \"nph = of_count_phandle_with_args()\" just counts\nnumber of phandles. But phandles may be empty. So of_parse_phandle() in\nthe parsing loop (0 \u003c a \u003c nph) may return NULL which is later dereferenced.\nAdjust this issue by adding NULL-return check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[Fixed title to fit within the prescribed 70-75 charcters]\n\n * CVE-2024-43861: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: qmi_wwan: fix memory leak for not ip packets\n\nFree the unused skb when not ip packets arrive.\n\n * CVE-2024-43871: In the Linux kernel, the following vulnerability has been resolved:\n\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\n\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().\n\n * CVE-2024-43882: In the Linux kernel, the following vulnerability has been resolved:\n\nexec: Fix ToCToU between perm check and set-uid/gid usage\n\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file's metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\n\nFor example, if a file could change permissions from executable and not\nset-id:\n\n---------x 1 root root 16048 Aug 7 13:16 target\n\nto set-id and non-executable:\n\n---S------ 1 root root 16048 Aug 7 13:16 target\n\nit is possible to gain root privileges when execution should have been\ndisallowed.\n\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, \"chmod o-x,u+s target\" makes \"target\" executable only\nby uid \"root\" and gid \"cdrom\", while also becoming setuid-root:\n\n-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target\n\nbecomes:\n\n-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target\n\nBut racing the chmod means users without group \"cdrom\" membership can\nget the permission to execute \"target\" just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of \"only cdrom\ngroup members can setuid to root\".\n\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.\n\n * CVE-2024-43889: In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix possible divide-by-0 panic in padata_mt_helper()\n\nWe are hit with a not easily reproducible divide-by-0 panic in padata.c at\nbootup time.\n\n [ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI\n [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1\n [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021\n [ 10.017908] Workqueue: events_unbound padata_mt_helper\n [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0\n :\n [ 10.017963] Call Trace:\n [ 10.017968] \u003cTASK\u003e\n [ 10.018004] ? padata_mt_helper+0x39/0xb0\n [ 10.018084] process_one_work+0x174/0x330\n [ 10.018093] worker_thread+0x266/0x3a0\n [ 10.018111] kthread+0xcf/0x100\n [ 10.018124] ret_from_fork+0x31/0x50\n [ 10.018138] ret_from_fork_asm+0x1a/0x30\n [ 10.018147] \u003c/TASK\u003e\n\nLooking at the padata_mt_helper() function, the only way a divide-by-0\npanic can happen is when ps-\u003echunk_size is 0. The way that chunk_size is\ninitialized in padata_do_multithreaded(), chunk_size can be 0 when the\nmin_chunk in the passed-in padata_mt_job structure is 0.\n\nFix this divide-by-0 panic by making sure that chunk_size will be at least\n1 no matter what the input parameters are.\n\n * CVE-2024-43890: In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix overflow in get_free_elt()\n\n\"tracing_map-\u003enext_elt\" in get_free_elt() is at risk of overflowing.\n\nOnce it overflows, new elements can still be inserted into the tracing_map\neven though the maximum number of elements (`max_elts`) has been reached.\nContinuing to insert elements after the overflow could result in the\ntracing_map containing \"tracing_map-\u003emax_size\" elements, leaving no empty\nentries.\nIf any attempt is made to insert an element into a full tracing_map using\n`__tracing_map_insert()`, it will cause an infinite loop with preemption\ndisabled, leading to a CPU hang problem.\n\nFix this by preventing any further increments to \"tracing_map-\u003enext_elt\"\nonce it reaches \"tracing_map-\u003emax_elt\".\n\n * CVE-2024-43893: In the Linux kernel, the following vulnerability has been resolved:\n\nserial: core: check uartclk for zero to avoid divide by zero\n\nCalling ioctl TIOCSSERIAL with an invalid baud_base can\nresult in uartclk being zero, which will result in a\ndivide by zero error in uart_get_divisor(). The check for\nuartclk being zero in uart_set_info() needs to be done\nbefore other settings are made as subsequent calls to\nioctl TIOCSSERIAL for the same port would be impacted if\nthe uartclk check was done where uartclk gets set.\n\nOops: divide error: 0000 PREEMPT SMP KASAN PTI\nRIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)\nCall Trace:\n \u003cTASK\u003e\nserial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576\n drivers/tty/serial/8250/8250_port.c:2589)\nserial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502\n drivers/tty/serial/8250/8250_port.c:2741)\nserial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)\nuart_change_line_settings (./include/linux/spinlock.h:376\n ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)\nuart_port_startup (drivers/tty/serial/serial_core.c:342)\nuart_startup (drivers/tty/serial/serial_core.c:368)\nuart_set_info (drivers/tty/serial/serial_core.c:1034)\nuart_set_info_user (drivers/tty/serial/serial_core.c:1059)\ntty_set_serial (drivers/tty/tty_io.c:2637)\ntty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)\n__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907\n fs/ioctl.c:893 fs/ioctl.c:893)\ndo_syscall_64 (arch/x86/entry/common.c:52\n (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nRule: add\n\n * CVE-2024-43894: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\n\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u003emode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.\n\n * CVE-2024-43907: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules\n\nCheck the pointer value to fix potential null pointer\ndereference\n\n * CVE-2024-43908: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix the null pointer dereference to ras_manager\n\nCheck ras_manager before using it\n\n * CVE-2024-43914: In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid5: avoid BUG_ON() while continue reshape after reassembling\n\nCurrently, mdadm support --revert-reshape to abort the reshape while\nreassembling, as the test 07revert-grow. However, following BUG_ON()\ncan be triggerred by the test:\n\nkernel BUG at drivers/md/raid5.c:6278!\ninvalid opcode: 0000 [#1] PREEMPT SMP PTI\nirq event stamp: 158985\nCPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94\nRIP: 0010:reshape_request+0x3f1/0xe60\nCall Trace:\n \u003cTASK\u003e\n raid5_sync_request+0x43d/0x550\n md_do_sync+0xb7a/0x2110\n md_thread+0x294/0x2b0\n kthread+0x147/0x1c0\n ret_from_fork+0x59/0x70\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\nRoot cause is that --revert-reshape update the raid_disks from 5 to 4,\nwhile reshape position is still set, and after reassembling the array,\nreshape position will be read from super block, then during reshape the\nchecking of 'writepos' that is caculated by old reshape position will\nfail.\n\nFix this panic the easy way first, by converting the BUG_ON() to\nWARN_ON(), and stop the reshape if checkings fail.\n\nNoted that mdadm must fix --revert-shape as well, and probably md/raid\nshould enhance metadata validation as well, however this means\nreassemble will fail and there must be user tools to fix the wrong\nmetadata.\n\n * CVE-2024-44935: In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: Fix null-ptr-deref in reuseport_add_sock().\n\nsyzbot reported a null-ptr-deref while accessing sk2-\u003esk_reuseport_cb in\nreuseport_add_sock(). [0]\n\nThe repro first creates a listener with SO_REUSEPORT. Then, it creates\nanother listener on the same port and concurrently closes the first\nlistener.\n\nThe second listen() calls reuseport_add_sock() with the first listener as\nsk2, where sk2-\u003esk_reuseport_cb is not expected to be cleared concurrently,\nbut the close() does clear it by reuseport_detach_sock().\n\nThe problem is SCTP does not properly synchronise reuseport_alloc(),\nreuseport_add_sock(), and reuseport_detach_sock().\n\nThe caller of reuseport_alloc() and reuseport_{add,detach}_sock() must\nprovide synchronisation for sockets that are classified into the same\nreuseport group.\n\nOtherwise, such sockets form multiple identical reuseport groups, and\nall groups except one would be silently dead.\n\n 1. Two sockets call listen() concurrently\n 2. No socket in the same group found in sctp_ep_hashtable[]\n 3. Two sockets call reuseport_alloc() and form two reuseport groups\n 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives\n incoming packets\n\nAlso, the reported null-ptr-deref could occur.\n\nTCP/UDP guarantees that would not happen by holding the hash bucket lock.\n\nLet's apply the locking strategy to __sctp_hash_endpoint() and\n__sctp_unhash_endpoint().\n\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\nCPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024\nRIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350\nCode: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 \u003c42\u003e 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14\nRSP: 0018:ffffc9000b947c98 EFLAGS: 00010202\nRAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012\nRBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385\nR10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0\nR13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000\nFS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n __sctp_hash_endpoint net/sctp/input.c:762 [inline]\n sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790\n sctp_listen_start net/sctp/socket.c:8570 [inline]\n sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625\n __sys_listen_socket net/socket.c:1883 [inline]\n __sys_listen+0x1b7/0x230 net/socket.c:1894\n __do_sys_listen net/socket.c:1902 [inline]\n __se_sys_listen net/socket.c:1900 [inline]\n __x64_sys_listen+0x5a/0x70 net/socket.c:1900\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f24e46039b9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 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 \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032\nRAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9\nRDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004\nRBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0\nR10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c\nR13:\n---truncated---\n\n * CVE-2024-44944: In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: use helper function to calculate expect ID\n\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.\n\n * CVE-2024-44947: In the Linux kernel, the following vulnerability has been resolved:\n\nfuse: Initialize beyond-EOF page contents before setting uptodate\n\nfuse_notify_store(), unlike fuse_do_readpage(), does not enable page\nzeroing (because it can be used to change partial page contents).\n\nSo fuse_notify_store() must be more careful to fully initialize page\ncontents (including parts of the page that are beyond end-of-file)\nbefore marking the page uptodate.\n\nThe current code can leave beyond-EOF page contents uninitialized, which\nmakes these uninitialized page contents visible to userspace via mmap().\n\nThis is an information leak, but only affects systems which do not\nenable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the\ncorresponding kernel command line parameter).\n\n * CVE-2024-44971: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()\n\nbcm_sf2_mdio_register() calls of_phy_find_device() and then\nphy_device_remove() in a loop to remove existing PHY devices.\nof_phy_find_device() eventually calls bus_find_device(), which calls\nget_device() on the returned struct device * to increment the refcount.\nThe current implementation does not decrement the refcount, which causes\nmemory leak.\n\nThis commit adds the missing phy_device_free() call to decrement the\nrefcount via put_device() to balance the refcount.\n\n * CVE-2024-44987: In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent UAF in ip6_send_skb()\n\nsyzbot reported an UAF in ip6_send_skb() [1]\n\nAfter ip6_local_out() has returned, we no longer can safely\ndereference rt, unless we hold rcu_read_lock().\n\nA similar issue has been fixed in commit\na688caa34beb (\"ipv6: take rcu lock in rawv6_send_hdrinc()\")\n\nAnother potential issue in ip6_finish_output2() is handled in a\nseparate patch.\n\n[1]\n BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964\nRead of size 8 at addr ffff88806dde4858 by task syz.1.380/6530\n\nCPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:93 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964\n rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588\n rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x1a6/0x270 net/socket.c:745\n sock_write_iter+0x2dd/0x400 net/socket.c:1160\n do_iter_readv_writev+0x60a/0x890\n vfs_writev+0x37c/0xbb0 fs/read_write.c:971\n do_writev+0x1b1/0x350 fs/read_write.c:1018\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f936bf79e79\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79\nRDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004\nRBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8\n \u003c/TASK\u003e\n\nAllocated by task 6530:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n unpoison_slab_object mm/kasan/common.c:312 [inline]\n __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338\n kasan_slab_alloc include/linux/kasan.h:201 [inline]\n slab_post_alloc_hook mm/slub.c:3988 [inline]\n slab_alloc_node mm/slub.c:4037 [inline]\n kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044\n dst_alloc+0x12b/0x190 net/core/dst.c:89\n ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670\n make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]\n xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313\n ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257\n rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x1a6/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597\n ___sys_sendmsg net/socket.c:2651 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 45:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579\n poison_slab_object+0xe0/0x150 mm/kasan/common.c:240\n __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256\n kasan_slab_free include/linux/kasan.h:184 [inline]\n slab_free_hook mm/slub.c:2252 [inline]\n slab_free mm/slub.c:4473 [inline]\n kmem_cache_free+0x145/0x350 mm/slub.c:4548\n dst_destroy+0x2ac/0x460 net/core/dst.c:124\n rcu_do_batch kernel/rcu/tree.c:2569 [inline]\n rcu_core+0xafd/0x1830 kernel/rcu/tree.\n---truncated---\n\n * CVE-2024-44989: In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix xfrm real_dev null pointer dereference\n\nWe shouldn't set real_dev to NULL because packets can be in transit and\nxfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume\nreal_dev is set.\n\n Example trace:\n kernel: BUG: unable to handle page fault for address: 0000000000001030\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: #PF: supervisor write access in kernel mode\n kernel: #PF: error_code(0x0002) - not-present page\n kernel: PGD 0 P4D 0\n kernel: Oops: 0002 [#1] PREEMPT SMP\n kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12\n kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 \u003c83\u003e 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:\n kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60\n kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00\n kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014\n kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000\n kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000\n kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000\n kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: Call Trace:\n kernel: \u003cTASK\u003e\n kernel: ? __die+0x1f/0x60\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: ? page_fault_oops+0x142/0x4c0\n kernel: ? do_user_addr_fault+0x65/0x670\n kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: ? exc_page_fault+0x7b/0x180\n kernel: ? asm_exc_page_fault+0x22/0x30\n kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim]\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding]\n kernel: xfrm_output+0x61/0x3b0\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: ip_push_pending_frames+0x56/0x80\n\n * CVE-2024-44990: In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix null pointer deref in bond_ipsec_offload_ok\n\nWe must check if there is an active slave before dereferencing the pointer.\n\n * CVE-2024-44995: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix a deadlock problem when config TC during resetting\n\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n pf reset start\n ¦\n ?\n ......\nsetup tc ¦\n ¦ ?\n ? DOWN: napi_disable()\nnapi_disable()(skip) ¦\n ¦ ¦\n ? ?\n ...... ......\n ¦ ¦\n ? ¦\nnapi_enable() ¦\n ?\n UINIT: netif_napi_del()\n ¦\n ?\n ......\n ¦\n ?\n INIT: netif_napi_add()\n ¦\n ?\n ...... global reset start\n ¦ ¦\n ? ?\n UP: napi_enable()(skip) ......\n ¦ ¦\n ? ?\n ...... napi_disable()\n\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.\n\n * CVE-2024-44998: In the Linux kernel, the following vulnerability has been resolved:\n\natm: idt77252: prevent use after free in dequeue_rx()\n\nWe can't dereference \"skb\" after calling vcc-\u003epush() because the skb\nis released.\n\n * CVE-2024-44999: In the Linux kernel, the following vulnerability has been resolved:\n\ngtp: pull network headers in gtp_dev_xmit()\n\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\n\nWe must make sure the IPv4 or Ipv6 header is pulled in skb-\u003ehead\nbefore accessing fields in them.\n\nUse pskb_inet_may_pull() to fix this issue.\n\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n xmit_one net/core/dev.c:3580 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3145 [inline]\n packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n __sys_sendto+0x685/0x830 net/socket.c:2204\n __do_sys_sendto net/socket.c:2216 [inline]\n __se_sys_sendto net/socket.c:2212 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3994 [inline]\n slab_alloc_node mm/slub.c:4037 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n alloc_skb include/linux/skbuff.h:1320 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n packet_snd net/packet/af_packet.c:3088 [inline]\n packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n __sys_sendto+0x685/0x830 net/socket.c:2204\n __do_sys_sendto net/socket.c:2216 [inline]\n __se_sys_sendto net/socket.c:2212 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024\n\n * CVE-2024-45006: In the Linux kernel, the following vulnerability has been resolved:\n\nxhci: Fix Panther point NULL pointer deref at full-speed re-enumeration\n\nre-enumerating full-speed devices after a failed address device command\ncan trigger a NULL pointer dereference.\n\nFull-speed devices may need to reconfigure the endpoint 0 Max Packet Size\nvalue during enumeration. Usb core calls usb_ep0_reinit() in this case,\nwhich ends up calling xhci_configure_endpoint().\n\nOn Panther point xHC the xhci_configure_endpoint() function will\nadditionally check and reserve bandwidth in software. Other hosts do\nthis in hardware\n\nIf xHC address device command fails then a new xhci_virt_device structure\nis allocated as part of re-enabling the slot, but the bandwidth table\npointers are not set up properly here.\nThis triggers the NULL pointer dereference the next time usb_ep0_reinit()\nis called and xhci_configure_endpoint() tries to check and reserve\nbandwidth\n\n[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd\n[46710.713699] usb 3-1: Device not responding to setup address.\n[46710.917684] usb 3-1: Device not responding to setup address.\n[46711.125536] usb 3-1: device not accepting address 5, error -71\n[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[46711.125600] #PF: supervisor read access in kernel mode\n[46711.125603] #PF: error_code(0x0000) - not-present page\n[46711.125606] PGD 0 P4D 0\n[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI\n[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1\n[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.\n[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]\n[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c\n\nFix this by making sure bandwidth table pointers are set up correctly\nafter a failed address device command, and additionally by avoiding\nchecking for bandwidth in cases like this where no actual endpoints are\nadded or removed, i.e. only context for default control endpoint 0 is\nevaluated.\n\n * CVE-2024-45016: In the Linux kernel, the following vulnerability has been resolved:\n\nnetem: fix return value if duplicate enqueue fails\n\nThere is a bug in netem_enqueue() introduced by\ncommit 5845f706388a (\"net: netem: fix skb length BUG_ON in __skb_to_sgvec\")\nthat can lead to a use-after-free.\n\nThis commit made netem_enqueue() always return NET_XMIT_SUCCESS\nwhen a packet is duplicated, which can cause the parent qdisc's q.qlen\nto be mistakenly incremented. When this happens qlen_notify() may be\nskipped on the parent during destruction, leaving a dangling pointer\nfor some classful qdiscs like DRR.\n\nThere are two ways for the bug happen:\n\n- If the duplicated packet is dropped by rootq-\u003eenqueue() and then\n the original packet is also dropped.\n- If rootq-\u003eenqueue() sends the duplicated packet to a different qdisc\n and the original packet is dropped.\n\nIn both cases NET_XMIT_SUCCESS is returned even though no packets\nare enqueued at the netem qdisc.\n\nThe fix is to defer the enqueue of the duplicate packet until after\nthe original packet has been guaranteed to return NET_XMIT_SUCCESS.\n\n * CVE-2024-45018: In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: initialise extack before use\n\nFix missing initialisation of extack in flow offload.\n\n * CVE-2024-45021: In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg_write_event_control(): fix a user-triggerable oops\n\nwe are *not* guaranteed that anything past the terminating NUL\nis mapped (let alone initialized with anything sane).\n\n * CVE-2024-45025: In the Linux kernel, the following vulnerability has been resolved:\n\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\n\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old-\u003efull_fds_bits[] and fill\nthe rest with zeroes. What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear. Otherwise we are risking garbage from the last word\nwe'd copied.\n\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old-\u003emax_fds, so there's no open descriptors\npast count, let alone fully occupied words in -\u003eopen_fds[],\nwhich is what bits in -\u003efull_fds_bits[] correspond to.\n\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds. In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\n\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in -\u003efull_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* 'to' being above the current capacity of descriptor table\n\t* 'from' being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\n\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet's try to fix copy_fd_bitmaps() first.\n\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it's 'count' argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it'll generate\nplain memcpy()+memset().\n\nReproducer added to tools/testing/selftests/core/close_range_test.c\n\n * CVE-2024-45026: In the Linux kernel, the following vulnerability has been resolved:\n\ns390/dasd: fix error recovery leading to data corruption on ESE devices\n\nExtent Space Efficient (ESE) or thin provisioned volumes need to be\nformatted on demand during usual IO processing.\n\nThe dasd_ese_needs_format function checks for error codes that signal\nthe non existence of a proper track format.\n\nThe check for incorrect length is to imprecise since other error cases\nleading to transport of insufficient data also have this flag set.\nThis might lead to data corruption in certain error cases for example\nduring a storage server warmstart.\n\nFix by removing the check for incorrect length and replacing by\nexplicitly checking for invalid track format in transport mode.\n\nAlso remove the check for file protected since this is not a valid\nESE handling case.\n\n * CVE-2024-45028: In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: mmc_test: Fix NULL dereference on allocation failure\n\nIf the \"test-\u003ehighmem = alloc_pages()\" allocation fails then calling\n__free_pages(test-\u003ehighmem) will result in a NULL dereference. Also\nchange the error code to -ENOMEM instead of returning success.\n\n * CVE-2024-46673: In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: aacraid: Fix double-free on probe failure\n\naac_probe_one() calls hardware-specific init functions through the\naac_driver_ident::init pointer, all of which eventually call down to\naac_init_adapter().\n\nIf aac_init_adapter() fails after allocating memory for aac_dev::queues,\nit frees the memory but does not clear that member.\n\nAfter the hardware-specific init function returns an error,\naac_probe_one() goes down an error path that frees the memory pointed to\nby aac_dev::queues, resulting.in a double-free.\n\n * CVE-2024-46674: In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: st: fix probed platform device ref count on probe error path\n\nThe probe function never performs any paltform device allocation, thus\nerror path \"undo_platform_dev_alloc\" is entirely bogus. It drops the\nreference count from the platform device being probed. If error path is\ntriggered, this will lead to unbalanced device reference counts and\npremature release of device resources, thus possible use-after-free when\nreleasing remaining devm-managed resources.\n\n * CVE-2024-46675: In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: core: Prevent USB core invalid event buffer address access\n\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n 1. In dwc3_gadget_suspend, there is a chance of a timeout when\n moving the USB core to the halt state after clearing the\n run/stop bit by software.\n 2. In dwc3_core_exit, the event buffer is cleared regardless of\n the USB core's status, which may lead to an SMMU faults and\n other memory issues. if the USB core tries to access the event\n buffer address.\n\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.\n\n * CVE-2024-46676: In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: pn533: Add poll mod list filling check\n\nIn case of im_protocols value is 1 and tm_protocols value is 0 this\ncombination successfully passes the check\n'if (!im_protocols \u0026\u0026 !tm_protocols)' in the nfc_start_poll().\nBut then after pn533_poll_create_mod_list() call in pn533_start_poll()\npoll mod list will remain empty and dev-\u003epoll_mod_count will remain 0\nwhich lead to division by zero.\n\nNormally no im protocol has value 1 in the mask, so this combination is\nnot expected by driver. But these protocol values actually come from\nuserspace via Netlink interface (NFC_CMD_START_POLL operation). So a\nbroken or malicious program may pass a message containing a \"bad\"\ncombination of protocol parameter values so that dev-\u003epoll_mod_count\nis not incremented inside pn533_poll_create_mod_list(), thus leading\nto division by zero.\nCall trace looks like:\nnfc_genl_start_poll()\n nfc_start_poll()\n -\u003estart_poll()\n pn533_start_poll()\n\nAdd poll mod list filling check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n * CVE-2024-46677: In the Linux kernel, the following vulnerability has been resolved:\n\ngtp: fix a potential NULL pointer dereference\n\nWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns a\nNULL pointer, but its callers only check for error pointers thus miss\nthe NULL pointer case.\n\nFix it by returning an error pointer with the error code carried from\nsockfd_lookup().\n\n(I found this bug during code inspection.)\n\n * CVE-2024-46679: In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: check device is present when getting link settings\n\nA sysfs reader can race with a device reset or removal, attempting to\nread device state when the device is not actually present. eg:\n\n [exception RIP: qed_get_current_link+17]\n #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]\n #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3\n #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4\n #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300\n #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c\n #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b\n #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3\n #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1\n #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f\n #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb\n\n crash\u003e struct net_device.state ffff9a9d21336000\n state = 5,\n\nstate 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).\nThe device is not present, note lack of __LINK_STATE_PRESENT (0b10).\n\nThis is the same sort of panic as observed in commit 4224cfd7fb65\n(\"net-sysfs: add check for netdevice being present to speed_show\").\n\nThere are many other callers of __ethtool_get_link_ksettings() which\ndon't have a device presence check.\n\nMove this check into ethtool to protect all callers.\n\n * CVE-2024-46685: In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: single: fix potential NULL dereference in pcs_get_function()\n\npinmux_generic_get_function() can return NULL and the pointer 'function'\nwas dereferenced without checking against NULL. Add checking of pointer\n'function' in pcs_get_function().\n\nFound by code review.\n\n * CVE-2024-46689: In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\n\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \"write\" into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\n\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\n\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\n\nI tested this on SA8155P with Xen.\n\n * CVE-2024-46702: In the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Mark XDomain as unplugged when router is removed\n\nI noticed that when we do discrete host router NVM upgrade and it gets\nhot-removed from the PCIe side as a result of NVM firmware authentication,\nif there is another host connected with enabled paths we hang in tearing\nthem down. This is due to fact that the Thunderbolt networking driver\nalso tries to cleanup the paths and ends up blocking in\ntb_disconnect_xdomain_paths() waiting for the domain lock.\n\nHowever, at this point we already cleaned the paths in tb_stop() so\nthere is really no need for tb_disconnect_xdomain_paths() to do that\nanymore. Furthermore it already checks if the XDomain is unplugged and\nbails out early so take advantage of that and mark the XDomain as\nunplugged when we remove the parent router.\n\n * CVE-2024-46707: In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3\n\nOn a system with a GICv3, if a guest hasn't been configured with\nGICv3 and that the host is not capable of GICv2 emulation,\na write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.\n\nWe therefore try to emulate the SGI access, only to hit a NULL\npointer as no private interrupt is allocated (no GIC, remember?).\n\nThe obvious fix is to give the guest what it deserves, in the\nshape of a UNDEF exception.\n\n * CVE-2024-46719: In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: Fix null pointer dereference in trace\n\nucsi_register_altmode checks IS_ERR for the alt pointer and treats\nNULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,\nucsi_register_displayport returns NULL which causes a NULL pointer\ndereference in trace. Rather than return NULL, call\ntypec_port_register_altmode to register DisplayPort alternate mode\nas a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.\n\n * CVE-2024-46721: In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix possible NULL pointer dereference\n\nprofile-\u003eparent-\u003edents[AAFS_PROF_DIR] could be NULL only if its parent is made\nfrom __create_missing_ancestors(..) and 'ent-\u003eold' is NULL in\naa_replace_profiles(..).\nIn that case, it must return an error code and the code, -ENOENT represents\nits state that the path of its parent is not existed yet.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u003c4d\u003e 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0\nCall Trace:\n \u003cTASK\u003e\n ? show_regs+0x6d/0x80\n ? __die+0x24/0x80\n ? page_fault_oops+0x99/0x1b0\n ? kernelmode_fixup_or_oops+0xb2/0x140\n ? __bad_area_nosemaphore+0x1a5/0x2c0\n ? find_vma+0x34/0x60\n ? bad_area_nosemaphore+0x16/0x30\n ? do_user_addr_fault+0x2a2/0x6b0\n ? exc_page_fault+0x83/0x1b0\n ? asm_exc_page_fault+0x27/0x30\n ? aafs_create.constprop.0+0x7f/0x130\n ? aafs_create.constprop.0+0x51/0x130\n __aafs_profile_mkdir+0x3d6/0x480\n aa_replace_profiles+0x83f/0x1270\n policy_update+0xe3/0x180\n profile_load+0xbc/0x150\n ? rw_verify_area+0x47/0x140\n vfs_write+0x100/0x480\n ? __x64_sys_openat+0x55/0xa0\n ? syscall_exit_to_user_mode+0x86/0x260\n ksys_write+0x73/0x100\n __x64_sys_write+0x19/0x30\n x64_sys_call+0x7e/0x25c0\n do_syscall_64+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7be9f211c574\nCode: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89\nRSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574\nRDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004\nRBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80\nR13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30\n \u003c/TASK\u003e\nModules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas\nCR2: 0000000000000030\n---[ end trace 0000000000000000 ]---\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u003c4d\u003e 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000\n---truncated---\n\n * CVE-2024-46722: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix mc_data out-of-bounds read warning\n\nClear warning that read mc_data[i-1] may out-of-bounds.\n\n * CVE-2024-46723: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix ucode out-of-bounds read warning\n\nClear warning that read ucode[] may out-of-bounds.\n\n * CVE-2024-46724: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number\n\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error\n\n * CVE-2024-46725: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix out-of-bounds write warning\n\nCheck the ring type value to fix the out-of-bounds\nwrite warning\n\n * CVE-2024-46731: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: fix the Out-of-bounds read warning\n\nusing index i - 1U may beyond element index\nfor mc_data[] when i = 0.\n\n * CVE-2024-46737: In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix kernel crash if commands allocation fails\n\nIf the commands allocation fails in nvmet_tcp_alloc_cmds()\nthe kernel crashes in nvmet_tcp_release_queue_work() because of\na NULL pointer dereference.\n\n nvmet: failed to install queue 0 cntlid 1 ret 6\n Unable to handle kernel NULL pointer dereference at\n virtual address 0000000000000008\n\nFix the bug by setting queue-\u003enr_cmds to zero in case\nnvmet_tcp_alloc_cmd() fails.\n\n * CVE-2024-46738: In the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: Fix use-after-free when removing resource in vmci_resource_remove()\n\nWhen removing a resource from vmci_resource_table in\nvmci_resource_remove(), the search is performed using the resource\nhandle by comparing context and resource fields.\n\nIt is possible though to create two resources with different types\nbut same handle (same context and resource fields).\n\nWhen trying to remove one of the resources, vmci_resource_remove()\nmay not remove the intended one, but the object will still be freed\nas in the case of the datagram type in vmci_datagram_destroy_handle().\nvmci_resource_table will still hold a pointer to this freed resource\nleading to a use-after-free vulnerability.\n\nBUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\nBUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\nRead of size 4 at addr ffff88801c16d800 by task syz-executor197/1592\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106\n print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239\n __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425\n kasan_report+0x38/0x51 mm/kasan/report.c:442\n vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\n vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\n vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182\n ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444\n kref_put include/linux/kref.h:65 [inline]\n vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]\n vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195\n vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143\n __fput+0x261/0xa34 fs/file_table.c:282\n task_work_run+0xf0/0x194 kernel/task_work.c:164\n tracehook_notify_resume include/linux/tracehook.h:189 [inline]\n exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187\n exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220\n __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]\n syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313\n do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\n\nThis change ensures the type is also checked when removing\nthe resource from vmci_resource_table in vmci_resource_remove().\n\n * CVE-2024-46739: In the Linux kernel, the following vulnerability has been resolved:\n\nuio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind\n\nFor primary VM Bus channels, primary_channel pointer is always NULL. This\npointer is valid only for the secondary channels. Also, rescind callback\nis meant for primary channels only.\n\nFix NULL pointer dereference by retrieving the device_obj from the parent\nfor the primary channel.\n\n * CVE-2024-46740: In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix UAF caused by offsets overwrite\n\nBinder objects are processed and copied individually into the target\nbuffer during transactions. Any raw data in-between these objects is\ncopied as well. However, this raw data copy lacks an out-of-bounds\ncheck. If the raw data exceeds the data section size then the copy\noverwrites the offsets section. This eventually triggers an error that\nattempts to unwind the processed objects. However, at this point the\noffsets used to index these objects are now corrupted.\n\nUnwinding with corrupted offsets can result in decrements of arbitrary\nnodes and lead to their premature release. Other users of such nodes are\nleft with a dangling pointer triggering a use-after-free. This issue is\nmade evident by the following KASAN report (trimmed):\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c\n Write of size 4 at addr ffff47fc91598f04 by task binder-util/743\n\n CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1\n Hardware name: linux,dummy-virt (DT)\n Call trace:\n _raw_spin_lock+0xe4/0x19c\n binder_free_buf+0x128/0x434\n binder_thread_write+0x8a4/0x3260\n binder_ioctl+0x18f0/0x258c\n [...]\n\n Allocated by task 743:\n __kmalloc_cache_noprof+0x110/0x270\n binder_new_node+0x50/0x700\n binder_transaction+0x413c/0x6da8\n binder_thread_write+0x978/0x3260\n binder_ioctl+0x18f0/0x258c\n [...]\n\n Freed by task 745:\n kfree+0xbc/0x208\n binder_thread_read+0x1c5c/0x37d4\n binder_ioctl+0x16d8/0x258c\n [...]\n ==================================================================\n\nTo avoid this issue, let's check that the raw data copy is within the\nboundaries of the data section.\n\n * CVE-2024-46743: In the Linux kernel, the following vulnerability has been resolved:\n\nof/irq: Prevent device address out-of-bounds read in interrupt map walk\n\nWhen of_irq_parse_raw() is invoked with a device address smaller than\nthe interrupt parent node (from #address-cells property), KASAN detects\nthe following out-of-bounds read when populating the initial match table\n(dyndbg=\"func of_irq_parse_* +p\"):\n\n OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0\n OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2\n OF: intspec=4\n OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2\n OF: -\u003e addrsize=3\n ==================================================================\n BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0\n Read of size 4 at addr ffffff81beca5608 by task bash/764\n\n CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1\n Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023\n Call trace:\n dump_backtrace+0xdc/0x130\n show_stack+0x1c/0x30\n dump_stack_lvl+0x6c/0x84\n print_report+0x150/0x448\n kasan_report+0x98/0x140\n __asan_load4+0x78/0xa0\n of_irq_parse_raw+0x2b8/0x8d0\n of_irq_parse_one+0x24c/0x270\n parse_interrupts+0xc0/0x120\n of_fwnode_add_links+0x100/0x2d0\n fw_devlink_parse_fwtree+0x64/0xc0\n device_add+0xb38/0xc30\n of_device_add+0x64/0x90\n of_platform_device_create_pdata+0xd0/0x170\n of_platform_bus_create+0x244/0x600\n of_platform_notify+0x1b0/0x254\n blocking_notifier_call_chain+0x9c/0xd0\n __of_changeset_entry_notify+0x1b8/0x230\n __of_changeset_apply_notify+0x54/0xe4\n of_overlay_fdt_apply+0xc04/0xd94\n ...\n\n The buggy address belongs to the object at ffffff81beca5600\n which belongs to the cache kmalloc-128 of size 128\n The buggy address is located 8 bytes inside of\n 128-byte region [ffffff81beca5600, ffffff81beca5680)\n\n The buggy address belongs to the physical page:\n page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4\n head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0\n flags: 0x8000000000010200(slab|head|zone=2)\n raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300\n raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n \u003effffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ^\n ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc\n ==================================================================\n OF: -\u003e got it !\n\nPrevent the out-of-bounds read by copying the device address into a\nbuffer of sufficient size.\n\n * CVE-2024-46747: In the Linux kernel, the following vulnerability has been resolved:\n\nHID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup\n\nreport_fixup for the Cougar 500k Gaming Keyboard was not verifying\nthat the report descriptor size was correct before accessing it\n\n * CVE-2024-46755: In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()\n\nmwifiex_get_priv_by_id() returns the priv pointer corresponding to\nthe bss_num and bss_type, but without checking if the priv is actually\ncurrently in use.\nUnused priv pointers do not have a wiphy attached to them which can\nlead to NULL pointer dereferences further down the callstack. Fix\nthis by returning only used priv pointers which have priv-\u003ebss_mode\nset to something else than NL80211_IFTYPE_UNSPECIFIED.\n\nSaid NULL pointer dereference happened when an Accesspoint was started\nwith wpa_supplicant -i mlan0 with this config:\n\nnetwork={\n ssid=\"somessid\"\n mode=2\n frequency=2412\n key_mgmt=WPA-PSK WPA-PSK-SHA256\n proto=RSN\n group=CCMP\n pairwise=CCMP\n psk=\"12345678\"\n}\n\nWhen waiting for the AP to be established, interrupting wpa_supplicant\nwith \u003cctrl-c\u003e and starting it again this happens:\n\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140\n| Mem abort info:\n| ESR = 0x0000000096000004\n| EC = 0x25: DABT (current EL), IL = 32 bits\n| SET = 0, FnV = 0\n| EA = 0, S1PTW = 0\n| FSC = 0x04: level 0 translation fault\n| Data abort info:\n| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n| CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000\n| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000\n| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio\n+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs\n+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6\n| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18\n| Hardware name: somemachine (DT)\n| Workqueue: events sdio_irq_work\n| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]\n| sp : ffff8000818b3a70\n| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004\n| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9\n| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000\n| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000\n| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517\n| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1\n| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157\n| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124\n| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000\n| Call trace:\n| mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]\n| mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]\n| mwifiex_process_sta_event+0x298/0xf0c [mwifiex]\n| mwifiex_process_event+0x110/0x238 [mwifiex]\n| mwifiex_main_process+0x428/0xa44 [mwifiex]\n| mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]\n| process_sdio_pending_irqs+0x64/0x1b8\n| sdio_irq_work+0x4c/0x7c\n| process_one_work+0x148/0x2a0\n| worker_thread+0x2fc/0x40c\n| kthread+0x110/0x114\n| ret_from_fork+0x10/0x20\n| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)\n| ---[ end trace 0000000000000000 ]---\n\n * CVE-2024-46756: In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (w83627ehf) Fix underflows seen when writing limit attributes\n\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.\n\n * CVE-2024-46757: In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (nct6775-core) Fix underflows seen when writing limit attributes\n\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.\n\n * CVE-2024-46758: In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (lm95234) Fix underflows seen when writing limit attributes\n\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.\n\n * CVE-2024-46759: In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (adc128d818) Fix underflows seen when writing limit attributes\n\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.\n\n * CVE-2024-46761: In the Linux kernel, the following vulnerability has been resolved:\n\npci/hotplug/pnv_php: Fix hotplug driver crash on Powernv\n\nThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel\ncrash when we try to hot-unplug/disable the PCIe switch/bridge from\nthe PHB.\n\nThe crash occurs because although the MSI data structure has been\nreleased during disable/hot-unplug path and it has been assigned\nwith NULL, still during unregistration the code was again trying to\nexplicitly disable the MSI which causes the NULL pointer dereference and\nkernel crash.\n\nThe patch fixes the check during unregistration path to prevent invoking\npci_disable_msi/msix() since its data structure is already freed.\n\n * CVE-2024-46763: In the Linux kernel, the following vulnerability has been resolved:\n\nfou: Fix null-ptr-deref in GRO.\n\nWe observed a null-ptr-deref in fou_gro_receive() while shutting down\na host. [0]\n\nThe NULL pointer is sk-\u003esk_user_data, and the offset 8 is of protocol\nin struct fou.\n\nWhen fou_release() is called due to netns dismantle or explicit tunnel\nteardown, udp_tunnel_sock_release() sets NULL to sk-\u003esk_user_data.\nThen, the tunnel socket is destroyed after a single RCU grace period.\n\nSo, in-flight udp4_gro_receive() could find the socket and execute the\nFOU GRO handler, where sk-\u003esk_user_data could be NULL.\n\nLet's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL\nchecks in FOU GRO handlers.\n\n[0]:\nBUG: kernel NULL pointer dereference, address: 0000000000000008\n PF: supervisor read access in kernel mode\n PF: error_code(0x0000) - not-present page\nPGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0\nSMP PTI\nCPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1\nHardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017\nRIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]\nCode: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 \u003c0f\u003e b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42\nRSP: 0018:ffffa330c0003d08 EFLAGS: 00010297\nRAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010\nRDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08\nRBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002\nR10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400\nR13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0\nFS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u003cIRQ\u003e\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)\n ? no_context (arch/x86/mm/fault.c:752)\n ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)\n ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)\n ? fou_gro_receive (net/ipv4/fou.c:233) [fou]\n udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)\n udp4_gro_receive (net/ipv4/udp_offload.c:604)\n inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))\n dev_gro_receive (net/core/dev.c:6035 (discriminator 4))\n napi_gro_receive (net/core/dev.c:6170)\n ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]\n ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]\n napi_poll (net/core/dev.c:6847)\n net_rx_action (net/core/dev.c:6917)\n __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)\n asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)\n\u003c/IRQ\u003e\n do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)\n irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)\n common_interrupt (arch/x86/kernel/irq.c:239)\n asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)\nRIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)\nCode: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 \u003cfa\u003e c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00\nRSP: 0018:ffffffffb5603e58 EFLAGS: 00000246\nRAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900\nRDX: ffff93daee800000 RSI: ffff93d\n---truncated---\n\n * CVE-2024-46781: In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix missing cleanup on rollforward recovery error\n\nIn an error injection test of a routine for mount-time recovery, KASAN\nfound a use-after-free bug.\n\nIt turned out that if data recovery was performed using partial logs\ncreated by dsync writes, but an error occurred before starting the log\nwriter to create a recovered checkpoint, the inodes whose data had been\nrecovered were left in the ns_dirty_files list of the nilfs object and\nwere not freed.\n\nFix this issue by cleaning up inodes that have read the recovery data if\nthe recovery routine fails midway before the log writer starts.\n\n * CVE-2024-46782: In the Linux kernel, the following vulnerability has been resolved:\n\nila: call nf_unregister_net_hooks() sooner\n\nsyzbot found an use-after-free Read in ila_nf_input [1]\n\nIssue here is that ila_xlat_exit_net() frees the rhashtable,\nthen call nf_unregister_net_hooks().\n\nIt should be done in the reverse way, with a synchronize_rcu().\n\nThis is a good match for a pre_exit() method.\n\n[1]\n BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]\n BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]\n BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672\nRead of size 4 at addr ffff888064620008 by task ksoftirqd/0/16\n\nCPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:93 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n rht_key_hashfn include/linux/rhashtable.h:159 [inline]\n __rhashtable_lookup include/linux/rhashtable.h:604 [inline]\n rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672\n ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]\n ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]\n ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312\n __netif_receive_skb_one_core net/core/dev.c:5661 [inline]\n __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775\n process_backlog+0x662/0x15b0 net/core/dev.c:6108\n __napi_poll+0xcb/0x490 net/core/dev.c:6772\n napi_poll net/core/dev.c:6841 [inline]\n net_rx_action+0x89b/0x1240 net/core/dev.c:6963\n handle_softirqs+0x2c4/0x970 kernel/softirq.c:554\n run_ksoftirqd+0xca/0x130 kernel/softirq.c:928\n smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u003c/TASK\u003e\n\nThe buggy address belongs to the physical page:\npage: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620\nflags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xbfffffff(buddy)\nraw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000\nraw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as freed\npage last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187\n set_page_owner include/linux/page_owner.h:32 [inline]\n post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493\n prep_new_page mm/page_alloc.c:1501 [inline]\n get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439\n __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695\n __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]\n alloc_pages_node_noprof include/linux/gfp.h:296 [inline]\n ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103\n __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130\n __do_kmalloc_node mm/slub.c:4146 [inline]\n __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164\n __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650\n bucket_table_alloc lib/rhashtable.c:186 [inline]\n rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071\n ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613\n ops_ini\n---truncated---\n\n * CVE-2024-46791: In the Linux kernel, the following vulnerability has been resolved:\n\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\n\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\n\nCPU0 CPU1\n---- ----\nmcp251x_open()\n mutex_lock(\u0026priv-\u003emcp_lock)\n request_threaded_irq()\n \u003cinterrupt\u003e\n mcp251x_can_ist()\n mutex_lock(\u0026priv-\u003emcp_lock)\n mcp251x_hw_wake()\n disable_irq() \u003c-- deadlock\n\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn't matter if it's still\nrunning.\n\n * CVE-2024-46798: In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: dapm: Fix UAF for snd_soc_pcm_runtime object\n\nWhen using kernel with the following extra config,\n\n - CONFIG_KASAN=y\n - CONFIG_KASAN_GENERIC=y\n - CONFIG_KASAN_INLINE=y\n - CONFIG_KASAN_VMALLOC=y\n - CONFIG_FRAME_WARN=4096\n\nkernel detects that snd_pcm_suspend_all() access a freed\n'snd_soc_pcm_runtime' object when the system is suspended, which\nleads to a use-after-free bug:\n\n[ 52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270\n[ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330\n\n[ 52.047785] Call trace:\n[ 52.047787] dump_backtrace+0x0/0x3c0\n[ 52.047794] show_stack+0x34/0x50\n[ 52.047797] dump_stack_lvl+0x68/0x8c\n[ 52.047802] print_address_description.constprop.0+0x74/0x2c0\n[ 52.047809] kasan_report+0x210/0x230\n[ 52.047815] __asan_report_load1_noabort+0x3c/0x50\n[ 52.047820] snd_pcm_suspend_all+0x1a8/0x270\n[ 52.047824] snd_soc_suspend+0x19c/0x4e0\n\nThe snd_pcm_sync_stop() has a NULL check on 'substream-\u003eruntime' before\nmaking any access. So we need to always set 'substream-\u003eruntime' to NULL\neverytime we kfree() it.\n\n * CVE-2024-46800: In the Linux kernel, the following vulnerability has been resolved:\n\nsch/netem: fix use after free in netem_dequeue\n\nIf netem_dequeue() enqueues packet to inner qdisc and that qdisc\nreturns __NET_XMIT_STOLEN. The packet is dropped but\nqdisc_tree_reduce_backlog() is not called to update the parent's\nq.qlen, leading to the similar use-after-free as Commit\ne04991a48dbaf382 (\"netem: fix return value if duplicate enqueue\nfails\")\n\nCommands to trigger KASAN UaF:\n\nip link add type dummy\nip link set lo up\nip link set dummy0 up\ntc qdisc add dev lo parent root handle 1: drr\ntc filter add dev lo parent 1: basic classid 1:1\ntc class add dev lo classid 1:1 drr\ntc qdisc add dev lo parent 1:1 handle 2: netem\ntc qdisc add dev lo parent 2: handle 3: drr\ntc filter add dev lo parent 3: basic classid 3:1 action mirred egress\nredirect dev dummy0\ntc class add dev lo classid 3:1 drr\nping -c1 -W0.01 localhost # Trigger bug\ntc class del dev lo classid 1:1\ntc class add dev lo classid 1:1 drr\nping -c1 -W0.01 localhost # UaF",
|
|
"Advisory": {
|
|
"From": "errata.altlinux.org",
|
|
"Severity": "High",
|
|
"Rights": "Copyright 2024 BaseALT Ltd.",
|
|
"Issued": {
|
|
"Date": "2024-09-30"
|
|
},
|
|
"Updated": {
|
|
"Date": "2024-09-30"
|
|
},
|
|
"BDUs": [
|
|
{
|
|
"ID": "BDU:2024-04680",
|
|
"CVSS": "AV:N/AC:H/Au:N/C:C/I:C/A:C",
|
|
"CVSS3": "AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-119",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-04680",
|
|
"Impact": "High",
|
|
"Public": "20240619"
|
|
},
|
|
{
|
|
"ID": "BDU:2024-05829",
|
|
"CVSS": "AV:L/AC:L/Au:S/C:P/I:P/A:P",
|
|
"CVSS3": "AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
|
|
"CWE": "CWE-120",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-05829",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "BDU:2024-05830",
|
|
"CVSS": "AV:N/AC:L/Au:S/C:C/I:C/A:C",
|
|
"CVSS3": "AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-121",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-05830",
|
|
"Impact": "High",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "BDU:2024-06063",
|
|
"CVSS": "AV:L/AC:L/Au:S/C:P/I:N/A:C",
|
|
"CVSS3": "AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-06063",
|
|
"Impact": "Low",
|
|
"Public": "20240703"
|
|
},
|
|
{
|
|
"ID": "BDU:2024-06072",
|
|
"CVSS": "AV:L/AC:L/Au:S/C:C/I:C/A:C",
|
|
"CVSS3": "AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-06072",
|
|
"Impact": "High",
|
|
"Public": "20240504"
|
|
},
|
|
{
|
|
"ID": "BDU:2024-06082",
|
|
"CVSS": "AV:L/AC:L/Au:S/C:N/I:N/A:C",
|
|
"CVSS3": "AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-770",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-06082",
|
|
"Impact": "Low",
|
|
"Public": "20240402"
|
|
},
|
|
{
|
|
"ID": "BDU:2024-06732",
|
|
"CVSS": "AV:A/AC:H/Au:S/C:P/I:P/A:P",
|
|
"CVSS3": "AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
|
|
"CWE": "CWE-457",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-06732",
|
|
"Impact": "Low",
|
|
"Public": "20240808"
|
|
},
|
|
{
|
|
"ID": "BDU:2024-06745",
|
|
"CVSS": "AV:L/AC:L/Au:S/C:N/I:N/A:C",
|
|
"CVSS3": "AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-06745",
|
|
"Impact": "Low",
|
|
"Public": "20240809"
|
|
},
|
|
{
|
|
"ID": "BDU:2024-07483",
|
|
"CVSS": "AV:L/AC:H/Au:S/C:C/I:N/A:C",
|
|
"CVSS3": "AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-07483",
|
|
"Impact": "Low",
|
|
"Public": "20240702"
|
|
},
|
|
{
|
|
"ID": "BDU:2024-07484",
|
|
"CVSS": "AV:L/AC:L/Au:S/C:C/I:C/A:C",
|
|
"CVSS3": "AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-125, CWE-682, CWE-787",
|
|
"Href": "https://bdu.fstec.ru/vul/2024-07484",
|
|
"Impact": "High",
|
|
"Public": "20240510"
|
|
}
|
|
],
|
|
"CVEs": [
|
|
{
|
|
"ID": "CVE-2023-52889",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2023-52889",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-36978",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-36978",
|
|
"Impact": "High",
|
|
"Public": "20240619"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-39468",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-39468",
|
|
"Impact": "Low",
|
|
"Public": "20240625"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-39482",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-770",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-39482",
|
|
"Impact": "Low",
|
|
"Public": "20240705"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-39484",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-770",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-39484",
|
|
"Impact": "Low",
|
|
"Public": "20240705"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-39487",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-39487",
|
|
"Impact": "High",
|
|
"Public": "20240709"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-39495",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-39495",
|
|
"Impact": "High",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-39506",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-39506",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40902",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-120",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902",
|
|
"Impact": "High",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40904",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-Other",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40904",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40905",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40905",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40912",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40912",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40932",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40932",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40934",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40934",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40958",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40958",
|
|
"Impact": "High",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40959",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40959",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40960",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40960",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40961",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40961",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40980",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40980",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40981",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-40995",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-835",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-40995",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41000",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-190",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41000",
|
|
"Impact": "High",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41006",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41006",
|
|
"Impact": "Low",
|
|
"Public": "20240712"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41007",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41007",
|
|
"Impact": "Low",
|
|
"Public": "20240715"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41011",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-682",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41011",
|
|
"Impact": "High",
|
|
"Public": "20240718"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41012",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41012",
|
|
"Impact": "Low",
|
|
"Public": "20240723"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41040",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41040",
|
|
"Impact": "High",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41046",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-415",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41046",
|
|
"Impact": "High",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41049",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41049",
|
|
"Impact": "High",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41055",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41055",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41059",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-908",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41059",
|
|
"Impact": "High",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41063",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41063",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41064",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41064",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41070",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41070",
|
|
"Impact": "High",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41087",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-415",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41087",
|
|
"Impact": "High",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41089",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41089",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41092",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41092",
|
|
"Impact": "High",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41095",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41095",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-41097",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-41097",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42070",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42070",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42076",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-908",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42076",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42077",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42077",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42082",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-770",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42082",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42090",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42090",
|
|
"Impact": "Low",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42093",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42093",
|
|
"Impact": "High",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42094",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42094",
|
|
"Impact": "High",
|
|
"Public": "20240729"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42101",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42101",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42102",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-369",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42102",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42104",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42104",
|
|
"Impact": "High",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42131",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-190",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42131",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42137",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42137",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42148",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-129",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42148",
|
|
"Impact": "High",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42152",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42152",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42153",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42154",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
|
|
"CWE": "CWE-754",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42157",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
|
|
"CWE": "NVD-CWE-Other",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42157",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42161",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:H",
|
|
"CWE": "CWE-908",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42161",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42223",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-190",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42223",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42224",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H",
|
|
"CWE": "CWE-754",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42224",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42229",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
|
|
"CWE": "NVD-CWE-Other",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42229",
|
|
"Impact": "Low",
|
|
"Public": "20240730"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42232",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42232",
|
|
"Impact": "Low",
|
|
"Public": "20240807"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42236",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42236",
|
|
"Impact": "Low",
|
|
"Public": "20240807"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42244",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42244",
|
|
"Impact": "Low",
|
|
"Public": "20240807"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42247",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-770",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42247",
|
|
"Impact": "Low",
|
|
"Public": "20240807"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42259",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-131",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42259",
|
|
"Impact": "Low",
|
|
"Public": "20240814"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42271",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42271",
|
|
"Impact": "High",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42280",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42280",
|
|
"Impact": "High",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42283",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-908",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42283",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42284",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-754",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42284",
|
|
"Impact": "High",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42285",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42285",
|
|
"Impact": "High",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42286",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42286",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42287",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42287",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42288",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42288",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42289",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42289",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42301",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-129",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42301",
|
|
"Impact": "High",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42302",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42302",
|
|
"Impact": "High",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42308",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42308",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42309",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42309",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42310",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42310",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42311",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-908",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42311",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-42313",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-42313",
|
|
"Impact": "High",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43828",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-835",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43828",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43856",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-770",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43856",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43858",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-129",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43858",
|
|
"Impact": "High",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43860",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43860",
|
|
"Impact": "Low",
|
|
"Public": "20240817"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43861",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43861",
|
|
"Impact": "Low",
|
|
"Public": "20240820"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43871",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871",
|
|
"Impact": "Low",
|
|
"Public": "20240821"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43882",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-367",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43882",
|
|
"Impact": "High",
|
|
"Public": "20240821"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43889",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-369",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43889",
|
|
"Impact": "Low",
|
|
"Public": "20240826"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43890",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-190",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43890",
|
|
"Impact": "Low",
|
|
"Public": "20240826"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43893",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-369",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43893",
|
|
"Impact": "Low",
|
|
"Public": "20240826"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43894",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43894",
|
|
"Impact": "Low",
|
|
"Public": "20240826"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43907",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43907",
|
|
"Impact": "Low",
|
|
"Public": "20240826"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43908",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43908",
|
|
"Impact": "Low",
|
|
"Public": "20240826"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-43914",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-43914",
|
|
"Impact": "Low",
|
|
"Public": "20240826"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44935",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44935",
|
|
"Impact": "Low",
|
|
"Public": "20240826"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44944",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944",
|
|
"Impact": "Low",
|
|
"Public": "20240830"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44947",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
|
|
"CWE": "CWE-665",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44947",
|
|
"Impact": "Low",
|
|
"Public": "20240902"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44971",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-401",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44971",
|
|
"Impact": "Low",
|
|
"Public": "20240904"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44987",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44987",
|
|
"Impact": "High",
|
|
"Public": "20240904"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44989",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44989",
|
|
"Impact": "Low",
|
|
"Public": "20240904"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44990",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44990",
|
|
"Impact": "Low",
|
|
"Public": "20240904"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44995",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44995",
|
|
"Impact": "Low",
|
|
"Public": "20240904"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44998",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44998",
|
|
"Impact": "High",
|
|
"Public": "20240904"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-44999",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-908",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-44999",
|
|
"Impact": "High",
|
|
"Public": "20240904"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-45006",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-45006",
|
|
"Impact": "Low",
|
|
"Public": "20240904"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-45016",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-45016",
|
|
"Impact": "Low",
|
|
"Public": "20240911"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-45018",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-665",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-45018",
|
|
"Impact": "Low",
|
|
"Public": "20240911"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-45021",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-45021",
|
|
"Impact": "Low",
|
|
"Public": "20240911"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-45025",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-45025",
|
|
"Impact": "Low",
|
|
"Public": "20240911"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-45026",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-45026",
|
|
"Impact": "High",
|
|
"Public": "20240911"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-45028",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-45028",
|
|
"Impact": "Low",
|
|
"Public": "20240911"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46673",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-415",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46673",
|
|
"Impact": "High",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46674",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46674",
|
|
"Impact": "High",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46675",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46675",
|
|
"Impact": "Low",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46676",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-369",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46676",
|
|
"Impact": "Low",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46677",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46677",
|
|
"Impact": "Low",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46679",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46679",
|
|
"Impact": "Low",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46685",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46685",
|
|
"Impact": "Low",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46689",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46689",
|
|
"Impact": "Low",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46702",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "NVD-CWE-noinfo",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46702",
|
|
"Impact": "Low",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46707",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46707",
|
|
"Impact": "Low",
|
|
"Public": "20240913"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46719",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46719",
|
|
"Impact": "Low",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46721",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46721",
|
|
"Impact": "Low",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46722",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46722",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46723",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46723",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46724",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46724",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46725",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-787",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46725",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46731",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46731",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46737",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46737",
|
|
"Impact": "Low",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46738",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46738",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46739",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46739",
|
|
"Impact": "Low",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46740",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46740",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46743",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46743",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46747",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
|
|
"CWE": "CWE-125",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46747",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46755",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46755",
|
|
"Impact": "Low",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46756",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-191",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46756",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46757",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-191",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46757",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46758",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-191",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46758",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46759",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-191",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46759",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46761",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46761",
|
|
"Impact": "Low",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46763",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-476",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46763",
|
|
"Impact": "Low",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46781",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46781",
|
|
"Impact": "Low",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46782",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46782",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46791",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
|
|
"CWE": "CWE-667",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46791",
|
|
"Impact": "Low",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46798",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46798",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
},
|
|
{
|
|
"ID": "CVE-2024-46800",
|
|
"CVSS3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
|
|
"CWE": "CWE-416",
|
|
"Href": "https://nvd.nist.gov/vuln/detail/CVE-2024-46800",
|
|
"Impact": "High",
|
|
"Public": "20240918"
|
|
}
|
|
],
|
|
"AffectedCPEs": {
|
|
"CPEs": [
|
|
"cpe:/o:alt:kworkstation:9",
|
|
"cpe:/o:alt:workstation:9",
|
|
"cpe:/o:alt:server:9",
|
|
"cpe:/o:alt:server-v:9",
|
|
"cpe:/o:alt:education:9",
|
|
"cpe:/o:alt:slinux:9",
|
|
"cpe:/o:alt:starterkit:p9",
|
|
"cpe:/o:alt:kworkstation:9.1",
|
|
"cpe:/o:alt:workstation:9.1",
|
|
"cpe:/o:alt:server:9.1",
|
|
"cpe:/o:alt:server-v:9.1",
|
|
"cpe:/o:alt:education:9.1",
|
|
"cpe:/o:alt:slinux:9.1",
|
|
"cpe:/o:alt:starterkit:9.1",
|
|
"cpe:/o:alt:kworkstation:9.2",
|
|
"cpe:/o:alt:workstation:9.2",
|
|
"cpe:/o:alt:server:9.2",
|
|
"cpe:/o:alt:server-v:9.2",
|
|
"cpe:/o:alt:education:9.2",
|
|
"cpe:/o:alt:slinux:9.2",
|
|
"cpe:/o:alt:starterkit:9.2"
|
|
]
|
|
}
|
|
}
|
|
},
|
|
"Criteria": {
|
|
"Operator": "AND",
|
|
"Criterions": [
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:1001",
|
|
"Comment": "ALT Linux must be installed"
|
|
}
|
|
],
|
|
"Criterias": [
|
|
{
|
|
"Operator": "OR",
|
|
"Criterions": [
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537001",
|
|
"Comment": "kernel-doc-un is earlier than 1:5.10.226-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537002",
|
|
"Comment": "kernel-headers-modules-un-def is earlier than 1:5.10.226-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537003",
|
|
"Comment": "kernel-headers-un-def is earlier than 1:5.10.226-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537004",
|
|
"Comment": "kernel-image-domU-un-def is earlier than 1:5.10.226-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537005",
|
|
"Comment": "kernel-image-un-def is earlier than 1:5.10.226-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537006",
|
|
"Comment": "kernel-modules-drm-ancient-un-def is earlier than 1:5.10.226-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537007",
|
|
"Comment": "kernel-modules-drm-nouveau-un-def is earlier than 1:5.10.226-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537008",
|
|
"Comment": "kernel-modules-drm-un-def is earlier than 1:5.10.226-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537009",
|
|
"Comment": "kernel-modules-ide-un-def is earlier than 1:5.10.226-alt1"
|
|
},
|
|
{
|
|
"TestRef": "oval:org.altlinux.errata:tst:202412537010",
|
|
"Comment": "kernel-modules-staging-un-def is earlier than 1:5.10.226-alt1"
|
|
}
|
|
]
|
|
}
|
|
]
|
|
}
|
|
}
|
|
]
|
|
} |