diff --git a/cvrf_cves.json b/cvrf_cves.json new file mode 100644 index 0000000..98681a1 --- /dev/null +++ b/cvrf_cves.json @@ -0,0 +1,9412 @@ +{ + "CVE-2022-27239": { + "id": "CVE-2022-27239", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27239", + "severity": "Medium" + }, + "CVE-2022-3715": { + "id": "CVE-2022-3715", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3715", + "severity": "Low" + }, + "CVE-2021-41079": { + "id": "CVE-2021-41079", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41079", + "severity": "High" + }, + "CVE-2022-24795": { + "id": "CVE-2022-24795", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24795", + "severity": "High" + }, + "CVE-2022-1725": { + "id": "CVE-2022-1725", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1725", + "severity": "Low" + }, + "CVE-2024-21886": { + "id": "CVE-2024-21886", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21886", + "severity": "High" + }, + "CVE-2021-45486": { + "id": "CVE-2021-45486", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45486", + "severity": "Low" + }, + "CVE-2022-33068": { + "id": "CVE-2022-33068", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33068", + "severity": "Medium" + }, + "CVE-2021-40145": { + "id": "CVE-2021-40145", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40145", + "severity": "High" + }, + "CVE-2023-45862": { + "id": "CVE-2023-45862", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45862", + "severity": "High" + }, + "CVE-2021-34337": { + "id": "CVE-2021-34337", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34337", + "severity": "High" + }, + "CVE-2024-26625": { + "id": "CVE-2024-26625", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26625", + "severity": "Low" + }, + "CVE-2022-3479": { + "id": "CVE-2022-3479", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3479", + "severity": "High" + }, + "CVE-2021-36980": { + "id": "CVE-2021-36980", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36980", + "severity": "Medium" + }, + "CVE-2021-22898": { + "id": "CVE-2021-22898", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22898", + "severity": "Low" + }, + "CVE-2022-39377": { + "id": "CVE-2022-39377", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39377", + "severity": "Critical" + }, + "CVE-2021-32740": { + "id": "CVE-2021-32740", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32740", + "severity": "High" + }, + "CVE-2020-14347": { + "id": "CVE-2020-14347", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14347", + "severity": "High" + }, + "CVE-2023-40589": { + "id": "CVE-2023-40589", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40589", + "severity": "High" + }, + "CVE-2023-27349": { + "id": "CVE-2023-27349", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27349", + "severity": "High" + }, + "CVE-2022-21797": { + "id": "CVE-2022-21797", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21797", + "severity": "High" + }, + "CVE-2023-24580": { + "id": "CVE-2023-24580", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24580", + "severity": "High" + }, + "CVE-2023-51714": { + "id": "CVE-2023-51714", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51714", + "severity": "Critical" + }, + "CVE-2020-12867": { + "id": "CVE-2020-12867", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12867", + "severity": "Medium" + }, + "CVE-2020-26945": { + "id": "CVE-2020-26945", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26945", + "severity": "High" + }, + "CVE-2020-24659": { + "id": "CVE-2020-24659", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24659", + "severity": "High" + }, + "CVE-2021-3933": { + "id": "CVE-2021-3933", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3933", + "severity": "Medium" + }, + "CVE-2023-50229": { + "id": "CVE-2023-50229", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50229", + "severity": "High" + }, + "CVE-2024-36964": { + "id": "CVE-2024-36964", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36964", + "severity": "Medium" + }, + "CVE-2021-28957": { + "id": "CVE-2021-28957", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28957", + "severity": "Medium" + }, + "CVE-2024-28103": { + "id": "CVE-2024-28103", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28103", + "severity": "Medium" + }, + "CVE-2023-45322": { + "id": "CVE-2023-45322", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45322", + "severity": "Medium" + }, + "CVE-2024-22195": { + "id": "CVE-2024-22195", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22195", + "severity": "Medium" + }, + "CVE-2020-36280": { + "id": "CVE-2020-36280", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36280", + "severity": "High" + }, + "CVE-2022-46663": { + "id": "CVE-2022-46663", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46663", + "severity": "Medium" + }, + "CVE-2022-4338": { + "id": "CVE-2022-4338", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4338", + "severity": "Medium" + }, + "CVE-2021-42008": { + "id": "CVE-2021-42008", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42008", + "severity": "Medium" + }, + "CVE-2022-37966": { + "id": "CVE-2022-37966", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37966", + "severity": "High" + }, + "CVE-2023-52735": { + "id": "CVE-2023-52735", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52735", + "severity": "Low" + }, + "CVE-2022-36033": { + "id": "CVE-2022-36033", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36033", + "severity": "Medium" + }, + "CVE-2023-1981": { + "id": "CVE-2023-1981", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1981", + "severity": "Medium" + }, + "CVE-2024-31081": { + "id": "CVE-2024-31081", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31081", + "severity": "High" + }, + "CVE-2023-44271": { + "id": "CVE-2023-44271", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44271", + "severity": "High" + }, + "CVE-2022-44940": { + "id": "CVE-2022-44940", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44940", + "severity": "Critical" + }, + "CVE-2021-3973": { + "id": "CVE-2021-3973", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3973", + "severity": "High" + }, + "CVE-2022-1615": { + "id": "CVE-2022-1615", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1615", + "severity": "Medium" + }, + "CVE-2021-44716": { + "id": "CVE-2021-44716", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44716", + "severity": "High" + }, + "CVE-2020-0452": { + "id": "CVE-2020-0452", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0452", + "severity": "Critical" + }, + "CVE-2021-41771": { + "id": "CVE-2021-41771", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41771", + "severity": "Medium" + }, + "CVE-2022-41861": { + "id": "CVE-2022-41861", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41861", + "severity": "High" + }, + "CVE-2022-29155": { + "id": "CVE-2022-29155", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29155", + "severity": "Critical" + }, + "CVE-2023-36328": { + "id": "CVE-2023-36328", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36328", + "severity": "Critical" + }, + "CVE-2020-7060": { + "id": "CVE-2020-7060", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7060", + "severity": "Critical" + }, + "CVE-2022-1114": { + "id": "CVE-2022-1114", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1114", + "severity": "High" + }, + "CVE-2022-30699": { + "id": "CVE-2022-30699", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30699", + "severity": "Medium" + }, + "CVE-2020-25664": { + "id": "CVE-2020-25664", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25664", + "severity": "Low" + }, + "CVE-2022-37704": { + "id": "CVE-2022-37704", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37704", + "severity": "Medium" + }, + "CVE-2021-41496": { + "id": "CVE-2021-41496", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41496", + "severity": "High" + }, + "CVE-2022-4129": { + "id": "CVE-2022-4129", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4129", + "severity": "Medium" + }, + "CVE-2022-40617": { + "id": "CVE-2022-40617", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40617", + "severity": "Medium" + }, + "CVE-2023-4389": { + "id": "CVE-2023-4389", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4389", + "severity": "Medium" + }, + "CVE-2023-3180": { + "id": "CVE-2023-3180", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3180", + "severity": "Medium" + }, + "CVE-2022-44370": { + "id": "CVE-2022-44370", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44370", + "severity": "High" + }, + "CVE-2022-38784": { + "id": "CVE-2022-38784", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38784", + "severity": "High" + }, + "CVE-2020-24241": { + "id": "CVE-2020-24241", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24241", + "severity": "High" + }, + "CVE-2022-47943": { + "id": "CVE-2022-47943", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47943", + "severity": "Medium" + }, + "CVE-2021-33658": { + "id": "CVE-2021-33658", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33658", + "severity": "High" + }, + "CVE-2021-25786": { + "id": "CVE-2021-25786", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25786", + "severity": "High" + }, + "CVE-2021-42550": { + "id": "CVE-2021-42550", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42550", + "severity": "Medium" + }, + "CVE-2024-24474": { + "id": "CVE-2024-24474", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24474", + "severity": "High" + }, + "CVE-2023-26769": { + "id": "CVE-2023-26769", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26769", + "severity": "High" + }, + "CVE-2023-34432": { + "id": "CVE-2023-34432", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34432", + "severity": "Medium" + }, + "CVE-2021-3671": { + "id": "CVE-2021-3671", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3671", + "severity": "Medium" + }, + "CVE-2024-3657": { + "id": "CVE-2024-3657", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3657", + "severity": "Medium" + }, + "CVE-2022-3202": { + "id": "CVE-2022-3202", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3202", + "severity": "High" + }, + "CVE-2021-3549": { + "id": "CVE-2021-3549", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3549", + "severity": "High" + }, + "CVE-2022-35737": { + "id": "CVE-2022-35737", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35737", + "severity": "High" + }, + "CVE-2022-0216": { + "id": "CVE-2022-0216", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0216", + "severity": "Medium" + }, + "CVE-2022-2719": { + "id": "CVE-2022-2719", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2719", + "severity": "Medium" + }, + "CVE-2024-23849": { + "id": "CVE-2024-23849", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23849", + "severity": "Medium" + }, + "CVE-2022-48502": { + "id": "CVE-2022-48502", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48502", + "severity": "High" + }, + "CVE-2022-39028": { + "id": "CVE-2022-39028", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39028", + "severity": "High" + }, + "CVE-2023-45285": { + "id": "CVE-2023-45285", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45285", + "severity": "Medium" + }, + "CVE-2021-28711": { + "id": "CVE-2021-28711", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28711", + "severity": "Low" + }, + "CVE-2024-25062": { + "id": "CVE-2024-25062", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25062", + "severity": "High" + }, + "CVE-2023-3138": { + "id": "CVE-2023-3138", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3138", + "severity": "Medium" + }, + "CVE-2021-33037": { + "id": "CVE-2021-33037", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33037", + "severity": "Medium" + }, + "CVE-2021-23169": { + "id": "CVE-2021-23169", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23169", + "severity": "Medium" + }, + "CVE-2022-0778": { + "id": "CVE-2022-0778", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0778", + "severity": "High" + }, + "CVE-2020-24612": { + "id": "CVE-2020-24612", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24612", + "severity": "Medium" + }, + "CVE-2024-24899": { + "id": "CVE-2024-24899", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24899", + "severity": "High" + }, + "CVE-2021-44225": { + "id": "CVE-2021-44225", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44225", + "severity": "Medium" + }, + "CVE-2020-8178": { + "id": "CVE-2020-8178", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8178", + "severity": "Critical" + }, + "CVE-2021-25220": { + "id": "CVE-2021-25220", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25220", + "severity": "High" + }, + "CVE-2023-45234": { + "id": "CVE-2023-45234", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45234", + "severity": "Medium" + }, + "CVE-2022-24761": { + "id": "CVE-2022-24761", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24761", + "severity": "High" + }, + "CVE-2023-28711": { + "id": "CVE-2023-28711", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28711", + "severity": "Medium" + }, + "CVE-2023-5371": { + "id": "CVE-2023-5371", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5371", + "severity": "Medium" + }, + "CVE-2023-30577": { + "id": "CVE-2023-30577", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30577", + "severity": "High" + }, + "CVE-2023-26552": { + "id": "CVE-2023-26552", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26552", + "severity": "Medium" + }, + "CVE-2020-28241": { + "id": "CVE-2020-28241", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28241", + "severity": "Medium" + }, + "CVE-2022-48337": { + "id": "CVE-2022-48337", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48337", + "severity": "High" + }, + "CVE-2023-39328": { + "id": "CVE-2023-39328", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39328", + "severity": "Medium" + }, + "CVE-2022-21363": { + "id": "CVE-2022-21363", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21363", + "severity": "Medium" + }, + "CVE-2023-40305": { + "id": "CVE-2023-40305", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40305", + "severity": "High" + }, + "CVE-2021-32280": { + "id": "CVE-2021-32280", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32280", + "severity": "Medium" + }, + "CVE-2022-3239": { + "id": "CVE-2022-3239", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3239", + "severity": "High" + }, + "CVE-2019-16319": { + "id": "CVE-2019-16319", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16319", + "severity": "High" + }, + "CVE-2023-49083": { + "id": "CVE-2023-49083", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49083", + "severity": "Critical" + }, + "CVE-2021-38294": { + "id": "CVE-2021-38294", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38294", + "severity": "Critical" + }, + "CVE-2023-4016": { + "id": "CVE-2023-4016", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4016", + "severity": "Medium" + }, + "CVE-2022-3551": { + "id": "CVE-2022-3551", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3551", + "severity": "High" + }, + "CVE-2023-48237": { + "id": "CVE-2023-48237", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48237", + "severity": "Low" + }, + "CVE-2023-31436": { + "id": "CVE-2023-31436", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31436", + "severity": "High" + }, + "CVE-2021-46828": { + "id": "CVE-2021-46828", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46828", + "severity": "High" + }, + "CVE-2024-2002": { + "id": "CVE-2024-2002", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2002", + "severity": "High" + }, + "CVE-2023-52323": { + "id": "CVE-2023-52323", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52323", + "severity": "Medium" + }, + "CVE-2022-23633": { + "id": "CVE-2022-23633", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23633", + "severity": "Medium" + }, + "CVE-2023-7250": { + "id": "CVE-2023-7250", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7250", + "severity": "Medium" + }, + "CVE-2021-3608": { + "id": "CVE-2021-3608", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3608", + "severity": "Medium" + }, + "CVE-2022-29458": { + "id": "CVE-2022-29458", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29458", + "severity": "High" + }, + "CVE-2019-17570": { + "id": "CVE-2019-17570", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17570", + "severity": "Critical" + }, + "CVE-2022-30293": { + "id": "CVE-2022-30293", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30293", + "severity": "Critical" + }, + "CVE-2024-4340": { + "id": "CVE-2024-4340", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4340", + "severity": "High" + }, + "CVE-2023-50495": { + "id": "CVE-2023-50495", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50495", + "severity": "Medium" + }, + "CVE-2024-36008": { + "id": "CVE-2024-36008", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36008", + "severity": "Medium" + }, + "CVE-2022-0729": { + "id": "CVE-2022-0729", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0729", + "severity": "Medium" + }, + "CVE-2021-24122": { + "id": "CVE-2021-24122", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24122", + "severity": "Medium" + }, + "CVE-2020-16592": { + "id": "CVE-2020-16592", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16592", + "severity": "Medium" + }, + "CVE-2022-1304": { + "id": "CVE-2022-1304", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1304", + "severity": "High" + }, + "CVE-2022-40896": { + "id": "CVE-2022-40896", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40896", + "severity": "Medium" + }, + "CVE-2019-13619": { + "id": "CVE-2019-13619", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13619", + "severity": "High" + }, + "CVE-2023-51713": { + "id": "CVE-2023-51713", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51713", + "severity": "High" + }, + "CVE-2022-3491": { + "id": "CVE-2022-3491", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3491", + "severity": "High" + }, + "CVE-2024-26595": { + "id": "CVE-2024-26595", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26595", + "severity": "Medium" + }, + "CVE-2024-37894": { + "id": "CVE-2024-37894", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37894", + "severity": "Medium" + }, + "CVE-2021-36976": { + "id": "CVE-2021-36976", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36976", + "severity": "Medium" + }, + "CVE-2022-2132": { + "id": "CVE-2022-2132", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2132", + "severity": "High" + }, + "CVE-2024-26141": { + "id": "CVE-2024-26141", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26141", + "severity": "High" + }, + "CVE-2024-21742": { + "id": "CVE-2024-21742", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21742", + "severity": "Medium" + }, + "CVE-2023-38712": { + "id": "CVE-2023-38712", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38712", + "severity": "Medium" + }, + "CVE-2023-38037": { + "id": "CVE-2023-38037", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38037", + "severity": "Low" + }, + "CVE-2023-31975": { + "id": "CVE-2023-31975", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31975", + "severity": "Low" + }, + "CVE-2016-5007": { + "id": "CVE-2016-5007", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-5007", + "severity": "High" + }, + "CVE-2020-27830": { + "id": "CVE-2020-27830", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27830", + "severity": "High" + }, + "CVE-2024-21094": { + "id": "CVE-2024-21094", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21094", + "severity": "Low" + }, + "CVE-2023-0433": { + "id": "CVE-2023-0433", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0433", + "severity": "High" + }, + "CVE-2024-3019": { + "id": "CVE-2024-3019", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3019", + "severity": "High" + }, + "CVE-2023-4387": { + "id": "CVE-2023-4387", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4387", + "severity": "High" + }, + "CVE-2024-22099": { + "id": "CVE-2024-22099", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22099", + "severity": "High" + }, + "CVE-2024-38601": { + "id": "CVE-2024-38601", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38601", + "severity": "Medium" + }, + "CVE-2020-13114": { + "id": "CVE-2020-13114", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13114", + "severity": "High" + }, + "CVE-2020-11762": { + "id": "CVE-2020-11762", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11762", + "severity": "Medium" + }, + "CVE-2021-3748": { + "id": "CVE-2021-3748", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3748", + "severity": "High" + }, + "CVE-2021-28153": { + "id": "CVE-2021-28153", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28153", + "severity": "Medium" + }, + "CVE-2023-1382": { + "id": "CVE-2023-1382", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1382", + "severity": "Medium" + }, + "CVE-2021-30560": { + "id": "CVE-2021-30560", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30560", + "severity": "High" + }, + "CVE-2021-39293": { + "id": "CVE-2021-39293", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39293", + "severity": "High" + }, + "CVE-2024-6126": { + "id": "CVE-2024-6126", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6126", + "severity": "Low" + }, + "CVE-2020-11988": { + "id": "CVE-2020-11988", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11988", + "severity": "High" + }, + "CVE-2023-33201": { + "id": "CVE-2023-33201", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33201", + "severity": "Low" + }, + "CVE-2023-35828": { + "id": "CVE-2023-35828", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35828", + "severity": "Medium" + }, + "CVE-2022-2735": { + "id": "CVE-2022-2735", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2735", + "severity": "High" + }, + "CVE-2023-20900": { + "id": "CVE-2023-20900", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20900", + "severity": "Low" + }, + "CVE-2023-37369": { + "id": "CVE-2023-37369", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37369", + "severity": "High" + }, + "CVE-2021-31348": { + "id": "CVE-2021-31348", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31348", + "severity": "Medium" + }, + "CVE-2023-4623": { + "id": "CVE-2023-4623", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4623", + "severity": "High" + }, + "CVE-2021-23240": { + "id": "CVE-2021-23240", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23240", + "severity": "High" + }, + "CVE-2020-17489": { + "id": "CVE-2020-17489", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17489", + "severity": "Medium" + }, + "CVE-2022-29599": { + "id": "CVE-2022-29599", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29599", + "severity": "Critical" + }, + "CVE-2022-4415": { + "id": "CVE-2022-4415", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4415", + "severity": "Medium" + }, + "CVE-2023-1513": { + "id": "CVE-2023-1513", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1513", + "severity": "Medium" + }, + "CVE-2024-4855": { + "id": "CVE-2024-4855", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4855", + "severity": "Medium" + }, + "CVE-2023-32251": { + "id": "CVE-2023-32251", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32251", + "severity": "Medium" + }, + "CVE-2022-29486": { + "id": "CVE-2022-29486", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29486", + "severity": "Critical" + }, + "CVE-2021-21290": { + "id": "CVE-2021-21290", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21290", + "severity": "Medium" + }, + "CVE-2024-40997": { + "id": "CVE-2024-40997", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40997", + "severity": "Medium" + }, + "CVE-2022-22942": { + "id": "CVE-2022-22942", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22942", + "severity": "High" + }, + "CVE-2023-27538": { + "id": "CVE-2023-27538", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27538", + "severity": "Medium" + }, + "CVE-2023-30772": { + "id": "CVE-2023-30772", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30772", + "severity": "Medium" + }, + "CVE-2022-2521": { + "id": "CVE-2022-2521", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2521", + "severity": "Medium" + }, + "CVE-2022-48565": { + "id": "CVE-2022-48565", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48565", + "severity": "Critical" + }, + "CVE-2022-1280": { + "id": "CVE-2022-1280", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1280", + "severity": "Critical" + }, + "CVE-2021-22885": { + "id": "CVE-2021-22885", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22885", + "severity": "High" + }, + "CVE-2024-28835": { + "id": "CVE-2024-28835", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28835", + "severity": "Medium" + }, + "CVE-2021-3487": { + "id": "CVE-2021-3487", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3487", + "severity": "Medium" + }, + "CVE-2023-5717": { + "id": "CVE-2023-5717", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5717", + "severity": "Medium" + }, + "CVE-2024-38428": { + "id": "CVE-2024-38428", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38428", + "severity": "Medium" + }, + "CVE-2021-0561": { + "id": "CVE-2021-0561", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0561", + "severity": "Medium" + }, + "CVE-2022-48759": { + "id": "CVE-2022-48759", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48759", + "severity": "Low" + }, + "CVE-2023-7104": { + "id": "CVE-2023-7104", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7104", + "severity": "Medium" + }, + "CVE-2019-3828": { + "id": "CVE-2019-3828", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3828", + "severity": "Medium" + }, + "CVE-2024-27398": { + "id": "CVE-2024-27398", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27398", + "severity": "Low" + }, + "CVE-2021-29477": { + "id": "CVE-2021-29477", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29477", + "severity": "High" + }, + "CVE-2024-0727": { + "id": "CVE-2024-0727", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0727", + "severity": "High" + }, + "CVE-2021-20193": { + "id": "CVE-2021-20193", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20193", + "severity": "Medium" + }, + "CVE-2021-4202": { + "id": "CVE-2021-4202", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4202", + "severity": "Medium" + }, + "CVE-2022-43548": { + "id": "CVE-2022-43548", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43548", + "severity": "High" + }, + "CVE-2020-2806": { + "id": "CVE-2020-2806", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2806", + "severity": "Medium" + }, + "CVE-2022-1622": { + "id": "CVE-2022-1622", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1622", + "severity": "Medium" + }, + "CVE-2020-26575": { + "id": "CVE-2020-26575", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26575", + "severity": "High" + }, + "CVE-2021-36386": { + "id": "CVE-2021-36386", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36386", + "severity": "High" + }, + "CVE-2023-52076": { + "id": "CVE-2023-52076", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52076", + "severity": "High" + }, + "CVE-2020-27748": { + "id": "CVE-2020-27748", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27748", + "severity": "Medium" + }, + "CVE-2024-39489": { + "id": "CVE-2024-39489", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39489", + "severity": "Low" + }, + "CVE-2021-33391": { + "id": "CVE-2021-33391", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33391", + "severity": "Critical" + }, + "CVE-2022-20792": { + "id": "CVE-2022-20792", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20792", + "severity": "High" + }, + "CVE-2023-23969": { + "id": "CVE-2023-23969", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23969", + "severity": "High" + }, + "CVE-2022-41556": { + "id": "CVE-2022-41556", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41556", + "severity": "High" + }, + "CVE-2022-45047": { + "id": "CVE-2022-45047", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45047", + "severity": "Critical" + }, + "CVE-2022-29217": { + "id": "CVE-2022-29217", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29217", + "severity": "High" + }, + "CVE-2023-46847": { + "id": "CVE-2023-46847", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46847", + "severity": "Critical" + }, + "CVE-2024-5564": { + "id": "CVE-2024-5564", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5564", + "severity": "High" + }, + "CVE-2022-0529": { + "id": "CVE-2022-0529", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0529", + "severity": "High" + }, + "CVE-2021-20304": { + "id": "CVE-2021-20304", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20304", + "severity": "Medium" + }, + "CVE-2023-49502": { + "id": "CVE-2023-49502", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49502", + "severity": "High" + }, + "CVE-2022-1587": { + "id": "CVE-2022-1587", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1587", + "severity": "Critical" + }, + "CVE-2022-4696": { + "id": "CVE-2022-4696", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4696", + "severity": "High" + }, + "CVE-2023-4004": { + "id": "CVE-2023-4004", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4004", + "severity": "High" + }, + "CVE-2024-27437": { + "id": "CVE-2024-27437", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27437", + "severity": "Medium" + }, + "CVE-2022-36109": { + "id": "CVE-2022-36109", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36109", + "severity": "Medium" + }, + "CVE-2022-43552": { + "id": "CVE-2022-43552", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43552", + "severity": "Medium" + }, + "CVE-2022-4743": { + "id": "CVE-2022-4743", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4743", + "severity": "High" + }, + "CVE-2022-41903": { + "id": "CVE-2022-41903", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41903", + "severity": "Critical" + }, + "CVE-2023-23916": { + "id": "CVE-2023-23916", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23916", + "severity": "Medium" + }, + "CVE-2023-38288": { + "id": "CVE-2023-38288", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38288", + "severity": "Low" + }, + "CVE-2022-28506": { + "id": "CVE-2022-28506", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28506", + "severity": "High" + }, + "CVE-2023-22497": { + "id": "CVE-2023-22497", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22497", + "severity": "Critical" + }, + "CVE-2024-26306": { + "id": "CVE-2024-26306", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26306", + "severity": "Low" + }, + "CVE-2020-12695": { + "id": "CVE-2020-12695", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12695", + "severity": "High" + }, + "CVE-2023-46052": { + "id": "CVE-2023-46052", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46052", + "severity": "Low" + }, + "CVE-2020-35524": { + "id": "CVE-2020-35524", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35524", + "severity": "Medium" + }, + "CVE-2020-8151": { + "id": "CVE-2020-8151", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8151", + "severity": "High" + }, + "CVE-2020-8162": { + "id": "CVE-2020-8162", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8162", + "severity": "Critical" + }, + "CVE-2024-39301": { + "id": "CVE-2024-39301", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39301", + "severity": "Low" + }, + "CVE-2021-22884": { + "id": "CVE-2021-22884", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22884", + "severity": "High" + }, + "CVE-2023-38470": { + "id": "CVE-2023-38470", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38470", + "severity": "Medium" + }, + "CVE-2023-26604": { + "id": "CVE-2023-26604", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26604", + "severity": "High" + }, + "CVE-2021-3448": { + "id": "CVE-2021-3448", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3448", + "severity": "Low" + }, + "CVE-2024-27285": { + "id": "CVE-2024-27285", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27285", + "severity": "Medium" + }, + "CVE-2020-29363": { + "id": "CVE-2020-29363", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29363", + "severity": "High" + }, + "CVE-2020-27216": { + "id": "CVE-2020-27216", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27216", + "severity": "High" + }, + "CVE-2023-34475": { + "id": "CVE-2023-34475", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34475", + "severity": "Medium" + }, + "CVE-2023-38633": { + "id": "CVE-2023-38633", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38633", + "severity": "Medium" + }, + "CVE-2023-25173": { + "id": "CVE-2023-25173", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25173", + "severity": "Medium" + }, + "CVE-2021-35597": { + "id": "CVE-2021-35597", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35597", + "severity": "Medium" + }, + "CVE-2021-33813": { + "id": "CVE-2021-33813", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33813", + "severity": "High" + }, + "CVE-2023-30570": { + "id": "CVE-2023-30570", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30570", + "severity": "High" + }, + "CVE-2022-3970": { + "id": "CVE-2022-3970", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3970", + "severity": "Critical" + }, + "CVE-2022-4283": { + "id": "CVE-2022-4283", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4283", + "severity": "High" + }, + "CVE-2020-25219": { + "id": "CVE-2020-25219", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25219", + "severity": "High" + }, + "CVE-2023-7192": { + "id": "CVE-2023-7192", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7192", + "severity": "Medium" + }, + "CVE-2024-1086": { + "id": "CVE-2024-1086", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1086", + "severity": "High" + }, + "CVE-2021-33646": { + "id": "CVE-2021-33646", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33646", + "severity": "Low" + }, + "CVE-2023-6918": { + "id": "CVE-2023-6918", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6918", + "severity": "Medium" + }, + "CVE-2020-25969": { + "id": "CVE-2020-25969", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25969", + "severity": "Critical" + }, + "CVE-2023-1393": { + "id": "CVE-2023-1393", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1393", + "severity": "High" + }, + "CVE-2021-3185": { + "id": "CVE-2021-3185", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3185", + "severity": "Critical" + }, + "CVE-2022-24903": { + "id": "CVE-2022-24903", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24903", + "severity": "High" + }, + "CVE-2022-35252": { + "id": "CVE-2022-35252", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35252", + "severity": "Low" + }, + "CVE-2019-17177": { + "id": "CVE-2019-17177", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17177", + "severity": "Low" + }, + "CVE-2022-3627": { + "id": "CVE-2022-3627", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3627", + "severity": "Critical" + }, + "CVE-2022-2520": { + "id": "CVE-2022-2520", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2520", + "severity": "Medium" + }, + "CVE-2023-5341": { + "id": "CVE-2023-5341", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5341", + "severity": "Medium" + }, + "CVE-2021-38160": { + "id": "CVE-2021-38160", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38160", + "severity": "Medium" + }, + "CVE-2019-18874": { + "id": "CVE-2019-18874", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18874", + "severity": "High" + }, + "CVE-2021-33642": { + "id": "CVE-2021-33642", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33642", + "severity": "Low" + }, + "CVE-2021-23358": { + "id": "CVE-2021-23358", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23358", + "severity": "High" + }, + "CVE-2021-3611": { + "id": "CVE-2021-3611", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3611", + "severity": "Medium" + }, + "CVE-2021-22960": { + "id": "CVE-2021-22960", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22960", + "severity": "Medium" + }, + "CVE-2022-38349": { + "id": "CVE-2022-38349", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38349", + "severity": "High" + }, + "CVE-2023-0922": { + "id": "CVE-2023-0922", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0922", + "severity": "Medium" + }, + "CVE-2024-36950": { + "id": "CVE-2024-36950", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36950", + "severity": "Medium" + }, + "CVE-2023-45802": { + "id": "CVE-2023-45802", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45802", + "severity": "Critical" + }, + "CVE-2021-45417": { + "id": "CVE-2021-45417", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45417", + "severity": "High" + }, + "CVE-2022-3755": { + "id": "CVE-2022-3755", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3755", + "severity": "Medium" + }, + "CVE-2021-36221": { + "id": "CVE-2021-36221", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36221", + "severity": "High" + }, + "CVE-2023-22809": { + "id": "CVE-2023-22809", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22809", + "severity": "High" + }, + "CVE-2020-7663": { + "id": "CVE-2020-7663", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7663", + "severity": "High" + }, + "CVE-2022-0547": { + "id": "CVE-2022-0547", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0547", + "severity": "Critical" + }, + "CVE-2020-15522": { + "id": "CVE-2020-15522", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15522", + "severity": "Medium" + }, + "CVE-2023-34151": { + "id": "CVE-2023-34151", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34151", + "severity": "Medium" + }, + "CVE-2023-2731": { + "id": "CVE-2023-2731", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2731", + "severity": "Medium" + }, + "CVE-2022-3352": { + "id": "CVE-2022-3352", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3352", + "severity": "High" + }, + "CVE-2022-32149": { + "id": "CVE-2022-32149", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32149", + "severity": "High" + }, + "CVE-2021-20208": { + "id": "CVE-2021-20208", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20208", + "severity": "Medium" + }, + "CVE-2022-40307": { + "id": "CVE-2022-40307", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40307", + "severity": "Medium" + }, + "CVE-2021-23017": { + "id": "CVE-2021-23017", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23017", + "severity": "Critical" + }, + "CVE-2024-3096": { + "id": "CVE-2024-3096", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3096", + "severity": "Medium" + }, + "CVE-2019-3820": { + "id": "CVE-2019-3820", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3820", + "severity": "Medium" + }, + "CVE-2020-27225": { + "id": "CVE-2020-27225", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27225", + "severity": "High" + }, + "CVE-2023-24537": { + "id": "CVE-2023-24537", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24537", + "severity": "High" + }, + "CVE-2022-4603": { + "id": "CVE-2022-4603", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4603", + "severity": "High" + }, + "CVE-2023-39417": { + "id": "CVE-2023-39417", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39417", + "severity": "High" + }, + "CVE-2020-29651": { + "id": "CVE-2020-29651", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29651", + "severity": "High" + }, + "CVE-2022-20369": { + "id": "CVE-2022-20369", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20369", + "severity": "Medium" + }, + "CVE-2021-21381": { + "id": "CVE-2021-21381", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21381", + "severity": "High" + }, + "CVE-2020-14312": { + "id": "CVE-2020-14312", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14312", + "severity": "Medium" + }, + "CVE-2023-1193": { + "id": "CVE-2023-1193", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1193", + "severity": "Medium" + }, + "CVE-2024-36960": { + "id": "CVE-2024-36960", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36960", + "severity": "Medium" + }, + "CVE-2022-41946": { + "id": "CVE-2022-41946", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41946", + "severity": "Medium" + }, + "CVE-2019-1020001": { + "id": "CVE-2019-1020001", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1020001", + "severity": "High" + }, + "CVE-2021-22922": { + "id": "CVE-2021-22922", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22922", + "severity": "Medium" + }, + "CVE-2020-25678": { + "id": "CVE-2020-25678", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25678", + "severity": "Medium" + }, + "CVE-2023-4875": { + "id": "CVE-2023-4875", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4875", + "severity": "Medium" + }, + "CVE-2023-3019": { + "id": "CVE-2023-3019", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3019", + "severity": "Medium" + }, + "CVE-2020-14154": { + "id": "CVE-2020-14154", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14154", + "severity": "Medium" + }, + "CVE-2022-2343": { + "id": "CVE-2022-2343", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2343", + "severity": "Critical" + }, + "CVE-2024-3154": { + "id": "CVE-2024-3154", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3154", + "severity": "High" + }, + "CVE-2024-26627": { + "id": "CVE-2024-26627", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26627", + "severity": "High" + }, + "CVE-2023-0494": { + "id": "CVE-2023-0494", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0494", + "severity": "High" + }, + "CVE-2021-41159": { + "id": "CVE-2021-41159", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41159", + "severity": "Critical" + }, + "CVE-2021-34428": { + "id": "CVE-2021-34428", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34428", + "severity": "Low" + }, + "CVE-2023-2861": { + "id": "CVE-2023-2861", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2861", + "severity": "High" + }, + "CVE-2021-3200": { + "id": "CVE-2021-3200", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3200", + "severity": "Medium" + }, + "CVE-2021-3979": { + "id": "CVE-2021-3979", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3979", + "severity": "Medium" + }, + "CVE-2022-3725": { + "id": "CVE-2022-3725", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3725", + "severity": "High" + }, + "CVE-2021-32492": { + "id": "CVE-2021-32492", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32492", + "severity": "High" + }, + "CVE-2021-3630": { + "id": "CVE-2021-3630", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3630", + "severity": "Medium" + }, + "CVE-2023-6478": { + "id": "CVE-2023-6478", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6478", + "severity": "High" + }, + "CVE-2018-1311": { + "id": "CVE-2018-1311", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1311", + "severity": "High" + }, + "CVE-2023-3758": { + "id": "CVE-2023-3758", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3758", + "severity": "High" + }, + "CVE-2019-16707": { + "id": "CVE-2019-16707", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16707", + "severity": "Medium" + }, + "CVE-2023-32067": { + "id": "CVE-2023-32067", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32067", + "severity": "High" + }, + "CVE-2022-23305": { + "id": "CVE-2022-23305", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23305", + "severity": "Critical" + }, + "CVE-2021-44906": { + "id": "CVE-2021-44906", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44906", + "severity": "Medium" + }, + "CVE-2024-37371": { + "id": "CVE-2024-37371", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37371", + "severity": "None" + }, + "CVE-2020-13529": { + "id": "CVE-2020-13529", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13529", + "severity": "Medium" + }, + "CVE-2021-43527": { + "id": "CVE-2021-43527", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43527", + "severity": "Critical" + }, + "CVE-2021-3975": { + "id": "CVE-2021-3975", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3975", + "severity": "Medium" + }, + "CVE-2019-10063": { + "id": "CVE-2019-10063", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10063", + "severity": "High" + }, + "CVE-2023-4147": { + "id": "CVE-2023-4147", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4147", + "severity": "Medium" + }, + "CVE-2021-37714": { + "id": "CVE-2021-37714", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37714", + "severity": "High" + }, + "CVE-2022-41854": { + "id": "CVE-2022-41854", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41854", + "severity": "High" + }, + "CVE-2024-38625": { + "id": "CVE-2024-38625", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38625", + "severity": "Medium" + }, + "CVE-2023-41915": { + "id": "CVE-2023-41915", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41915", + "severity": "High" + }, + "CVE-2024-21506": { + "id": "CVE-2024-21506", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21506", + "severity": "Medium" + }, + "CVE-2023-1370": { + "id": "CVE-2023-1370", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1370", + "severity": "High" + }, + "CVE-2023-27371": { + "id": "CVE-2023-27371", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27371", + "severity": "High" + }, + "CVE-2022-46908": { + "id": "CVE-2022-46908", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46908", + "severity": "Critical" + }, + "CVE-2021-0938": { + "id": "CVE-2021-0938", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0938", + "severity": "Low" + }, + "CVE-2022-45693": { + "id": "CVE-2022-45693", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45693", + "severity": "High" + }, + "CVE-2020-16119": { + "id": "CVE-2020-16119", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16119", + "severity": "Medium" + }, + "CVE-2022-24921": { + "id": "CVE-2022-24921", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24921", + "severity": "High" + }, + "CVE-2023-22049": { + "id": "CVE-2023-22049", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22049", + "severity": "High" + }, + "CVE-2022-24303": { + "id": "CVE-2022-24303", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24303", + "severity": "Medium" + }, + "CVE-2024-35801": { + "id": "CVE-2024-35801", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35801", + "severity": "Medium" + }, + "CVE-2022-23806": { + "id": "CVE-2022-23806", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23806", + "severity": "High" + }, + "CVE-2021-27365": { + "id": "CVE-2021-27365", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27365", + "severity": "Medium" + }, + "CVE-2023-46137": { + "id": "CVE-2023-46137", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46137", + "severity": "Medium" + }, + "CVE-2023-1859": { + "id": "CVE-2023-1859", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1859", + "severity": "Medium" + }, + "CVE-2023-28366": { + "id": "CVE-2023-28366", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28366", + "severity": "High" + }, + "CVE-2024-20921": { + "id": "CVE-2024-20921", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20921", + "severity": "Medium" + }, + "CVE-2024-25580": { + "id": "CVE-2024-25580", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25580", + "severity": "Low" + }, + "CVE-2021-37530": { + "id": "CVE-2021-37530", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37530", + "severity": "Medium" + }, + "CVE-2019-10172": { + "id": "CVE-2019-10172", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10172", + "severity": "High" + }, + "CVE-2023-4622": { + "id": "CVE-2023-4622", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4622", + "severity": "High" + }, + "CVE-2020-22219": { + "id": "CVE-2020-22219", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-22219", + "severity": "Critical" + }, + "CVE-2024-35997": { + "id": "CVE-2024-35997", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35997", + "severity": "Medium" + }, + "CVE-2023-2091": { + "id": "CVE-2023-2091", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2091", + "severity": "High" + }, + "CVE-2022-23959": { + "id": "CVE-2022-23959", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23959", + "severity": "Critical" + }, + "CVE-2020-21528": { + "id": "CVE-2020-21528", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-21528", + "severity": "Medium" + }, + "CVE-2021-3178": { + "id": "CVE-2021-3178", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3178", + "severity": "High" + }, + "CVE-2023-36053": { + "id": "CVE-2023-36053", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36053", + "severity": "High" + }, + "CVE-2023-33285": { + "id": "CVE-2023-33285", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33285", + "severity": "Medium" + }, + "CVE-2022-1050": { + "id": "CVE-2022-1050", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1050", + "severity": "High" + }, + "CVE-2022-3016": { + "id": "CVE-2022-3016", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3016", + "severity": "Medium" + }, + "CVE-2022-0358": { + "id": "CVE-2022-0358", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0358", + "severity": "Medium" + }, + "CVE-2024-24557": { + "id": "CVE-2024-24557", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24557", + "severity": "High" + }, + "CVE-2023-22998": { + "id": "CVE-2023-22998", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22998", + "severity": "Medium" + }, + "CVE-2022-44640": { + "id": "CVE-2022-44640", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44640", + "severity": "High" + }, + "CVE-2023-38473": { + "id": "CVE-2023-38473", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38473", + "severity": "Medium" + }, + "CVE-2023-45935": { + "id": "CVE-2023-45935", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45935", + "severity": "Low" + }, + "CVE-2024-23638": { + "id": "CVE-2024-23638", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23638", + "severity": "Medium" + }, + "CVE-2023-45866": { + "id": "CVE-2023-45866", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45866", + "severity": "High" + }, + "CVE-2022-40304": { + "id": "CVE-2022-40304", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40304", + "severity": "High" + }, + "CVE-2022-39957": { + "id": "CVE-2022-39957", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39957", + "severity": "High" + }, + "CVE-2021-3682": { + "id": "CVE-2021-3682", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3682", + "severity": "Critical" + }, + "CVE-2022-23990": { + "id": "CVE-2022-23990", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23990", + "severity": "Critical" + }, + "CVE-2021-21261": { + "id": "CVE-2021-21261", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21261", + "severity": "High" + }, + "CVE-2021-21708": { + "id": "CVE-2021-21708", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21708", + "severity": "Critical" + }, + "CVE-2021-32617": { + "id": "CVE-2021-32617", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32617", + "severity": "Low" + }, + "CVE-2021-44647": { + "id": "CVE-2021-44647", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44647", + "severity": "Critical" + }, + "CVE-2022-29824": { + "id": "CVE-2022-29824", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29824", + "severity": "High" + }, + "CVE-2023-31486": { + "id": "CVE-2023-31486", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31486", + "severity": "High" + }, + "CVE-2023-1998": { + "id": "CVE-2023-1998", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1998", + "severity": "Medium" + }, + "CVE-2023-25399": { + "id": "CVE-2023-25399", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25399", + "severity": "Medium" + }, + "CVE-2022-31628": { + "id": "CVE-2022-31628", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31628", + "severity": "Medium" + }, + "CVE-2021-43566": { + "id": "CVE-2021-43566", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43566", + "severity": "Low" + }, + "CVE-2021-23840": { + "id": "CVE-2021-23840", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23840", + "severity": "High" + }, + "CVE-2023-48161": { + "id": "CVE-2023-48161", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48161", + "severity": "High" + }, + "CVE-2023-29469": { + "id": "CVE-2023-29469", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29469", + "severity": "Medium" + }, + "CVE-2020-11810": { + "id": "CVE-2020-11810", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11810", + "severity": "Low" + }, + "CVE-2021-33657": { + "id": "CVE-2021-33657", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33657", + "severity": "High" + }, + "CVE-2024-24784": { + "id": "CVE-2024-24784", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24784", + "severity": "High" + }, + "CVE-2022-32746": { + "id": "CVE-2022-32746", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32746", + "severity": "Medium" + }, + "CVE-2022-44730": { + "id": "CVE-2022-44730", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44730", + "severity": "Medium" + }, + "CVE-2024-21102": { + "id": "CVE-2024-21102", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21102", + "severity": "Medium" + }, + "CVE-2024-21733": { + "id": "CVE-2024-21733", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21733", + "severity": "High" + }, + "CVE-2023-5156": { + "id": "CVE-2023-5156", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5156", + "severity": "High" + }, + "CVE-2023-3195": { + "id": "CVE-2023-3195", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3195", + "severity": "Medium" + }, + "CVE-2021-22924": { + "id": "CVE-2021-22924", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22924", + "severity": "Medium" + }, + "CVE-2024-36917": { + "id": "CVE-2024-36917", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36917", + "severity": "Medium" + }, + "CVE-2023-5157": { + "id": "CVE-2023-5157", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5157", + "severity": "High" + }, + "CVE-2019-17567": { + "id": "CVE-2019-17567", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17567", + "severity": "Medium" + }, + "CVE-2023-0798": { + "id": "CVE-2023-0798", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0798", + "severity": "Medium" + }, + "CVE-2021-3640": { + "id": "CVE-2021-3640", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3640", + "severity": "Low" + }, + "CVE-2021-23437": { + "id": "CVE-2021-23437", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23437", + "severity": "High" + }, + "CVE-2021-47545": { + "id": "CVE-2021-47545", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47545", + "severity": "Medium" + }, + "CVE-2023-51074": { + "id": "CVE-2023-51074", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51074", + "severity": "Medium" + }, + "CVE-2023-6546": { + "id": "CVE-2023-6546", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6546", + "severity": "High" + }, + "CVE-2019-16892": { + "id": "CVE-2019-16892", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16892", + "severity": "Medium" + }, + "CVE-2022-48279": { + "id": "CVE-2022-48279", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48279", + "severity": "High" + }, + "CVE-2021-46854": { + "id": "CVE-2021-46854", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46854", + "severity": "High" + }, + "CVE-2022-1462": { + "id": "CVE-2022-1462", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1462", + "severity": "Medium" + }, + "CVE-2024-39292": { + "id": "CVE-2024-39292", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39292", + "severity": "High" + }, + "CVE-2022-37290": { + "id": "CVE-2022-37290", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37290", + "severity": "Medium" + }, + "CVE-2020-14954": { + "id": "CVE-2020-14954", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14954", + "severity": "Medium" + }, + "CVE-2023-36054": { + "id": "CVE-2023-36054", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36054", + "severity": "Medium" + }, + "CVE-2023-28370": { + "id": "CVE-2023-28370", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28370", + "severity": "Medium" + }, + "CVE-2023-31130": { + "id": "CVE-2023-31130", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31130", + "severity": "Medium" + }, + "CVE-2022-1925": { + "id": "CVE-2022-1925", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1925", + "severity": "High" + }, + "CVE-2024-2494": { + "id": "CVE-2024-2494", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2494", + "severity": "Medium" + }, + "CVE-2023-39325": { + "id": "CVE-2023-39325", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39325", + "severity": "Medium" + }, + "CVE-2023-3824": { + "id": "CVE-2023-3824", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3824", + "severity": "High" + }, + "CVE-2022-28735": { + "id": "CVE-2022-28735", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28735", + "severity": "High" + }, + "CVE-2023-22796": { + "id": "CVE-2023-22796", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22796", + "severity": "High" + }, + "CVE-2023-40660": { + "id": "CVE-2023-40660", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40660", + "severity": "Medium" + }, + "CVE-2021-45944": { + "id": "CVE-2021-45944", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45944", + "severity": "Medium" + }, + "CVE-2023-49100": { + "id": "CVE-2023-49100", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49100", + "severity": "High" + }, + "CVE-2023-1729": { + "id": "CVE-2023-1729", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1729", + "severity": "Low" + }, + "CVE-2021-27212": { + "id": "CVE-2021-27212", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27212", + "severity": "High" + }, + "CVE-2014-10402": { + "id": "CVE-2014-10402", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-10402", + "severity": "Medium" + }, + "CVE-2020-35457": { + "id": "CVE-2020-35457", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35457", + "severity": "High" + }, + "CVE-2023-32409": { + "id": "CVE-2023-32409", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32409", + "severity": "High" + }, + "CVE-2022-21166": { + "id": "CVE-2022-21166", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21166", + "severity": "Medium" + }, + "CVE-2020-12862": { + "id": "CVE-2020-12862", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12862", + "severity": "High" + }, + "CVE-2020-11987": { + "id": "CVE-2020-11987", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11987", + "severity": "Medium" + }, + "CVE-2024-26766": { + "id": "CVE-2024-26766", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26766", + "severity": "Low" + }, + "CVE-2022-3437": { + "id": "CVE-2022-3437", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3437", + "severity": "Medium" + }, + "CVE-2023-32001": { + "id": "CVE-2023-32001", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32001", + "severity": "Medium" + }, + "CVE-2021-33909": { + "id": "CVE-2021-33909", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33909", + "severity": "High" + }, + "CVE-2021-3802": { + "id": "CVE-2021-3802", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3802", + "severity": "Medium" + }, + "CVE-2024-38517": { + "id": "CVE-2024-38517", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38517", + "severity": "High" + }, + "CVE-2022-2663": { + "id": "CVE-2022-2663", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2663", + "severity": "Medium" + }, + "CVE-2021-44575": { + "id": "CVE-2021-44575", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44575", + "severity": "Medium" + }, + "CVE-2020-26259": { + "id": "CVE-2020-26259", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26259", + "severity": "High" + }, + "CVE-2020-25085": { + "id": "CVE-2020-25085", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25085", + "severity": "Medium" + }, + "CVE-2022-4292": { + "id": "CVE-2022-4292", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4292", + "severity": "Medium" + }, + "CVE-2023-1999": { + "id": "CVE-2023-1999", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1999", + "severity": "Medium" + }, + "CVE-2023-5344": { + "id": "CVE-2023-5344", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5344", + "severity": "High" + }, + "CVE-2024-37891": { + "id": "CVE-2024-37891", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37891", + "severity": "High" + }, + "CVE-2021-3470": { + "id": "CVE-2021-3470", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3470", + "severity": "Medium" + }, + "CVE-2022-2085": { + "id": "CVE-2022-2085", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2085", + "severity": "Medium" + }, + "CVE-2012-2738": { + "id": "CVE-2012-2738", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-2738", + "severity": "Medium" + }, + "CVE-2024-1681": { + "id": "CVE-2024-1681", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1681", + "severity": "Medium" + }, + "CVE-2021-20201": { + "id": "CVE-2021-20201", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20201", + "severity": "Medium" + }, + "CVE-2022-1786": { + "id": "CVE-2022-1786", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1786", + "severity": "High" + }, + "CVE-2021-40528": { + "id": "CVE-2021-40528", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40528", + "severity": "Medium" + }, + "CVE-2021-38593": { + "id": "CVE-2021-38593", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38593", + "severity": "High" + }, + "CVE-2022-32325": { + "id": "CVE-2022-32325", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32325", + "severity": "Medium" + }, + "CVE-2019-1010180": { + "id": "CVE-2019-1010180", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1010180", + "severity": "High" + }, + "CVE-2023-46751": { + "id": "CVE-2023-46751", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46751", + "severity": "High" + }, + "CVE-2020-14928": { + "id": "CVE-2020-14928", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14928", + "severity": "Medium" + }, + "CVE-2023-52730": { + "id": "CVE-2023-52730", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52730", + "severity": "Medium" + }, + "CVE-2023-29405": { + "id": "CVE-2023-29405", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29405", + "severity": "Critical" + }, + "CVE-2023-4273": { + "id": "CVE-2023-4273", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4273", + "severity": "High" + }, + "CVE-2022-42896": { + "id": "CVE-2022-42896", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42896", + "severity": "Medium" + }, + "CVE-2022-28737": { + "id": "CVE-2022-28737", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28737", + "severity": "High" + }, + "CVE-2021-39226": { + "id": "CVE-2021-39226", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39226", + "severity": "Medium" + }, + "CVE-2022-21682": { + "id": "CVE-2022-21682", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21682", + "severity": "Medium" + }, + "CVE-2020-26247": { + "id": "CVE-2020-26247", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26247", + "severity": "Medium" + }, + "CVE-2021-3498": { + "id": "CVE-2021-3498", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3498", + "severity": "High" + }, + "CVE-2023-5557": { + "id": "CVE-2023-5557", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5557", + "severity": "High" + }, + "CVE-2021-4185": { + "id": "CVE-2021-4185", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4185", + "severity": "Medium" + }, + "CVE-2021-21409": { + "id": "CVE-2021-21409", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21409", + "severity": "Medium" + }, + "CVE-2023-49081": { + "id": "CVE-2023-49081", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49081", + "severity": "High" + }, + "CVE-2024-26960": { + "id": "CVE-2024-26960", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960", + "severity": "Medium" + }, + "CVE-2020-25709": { + "id": "CVE-2020-25709", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25709", + "severity": "High" + }, + "CVE-2022-22707": { + "id": "CVE-2022-22707", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22707", + "severity": "Medium" + }, + "CVE-2022-27776": { + "id": "CVE-2022-27776", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27776", + "severity": "Low" + }, + "CVE-2020-8184": { + "id": "CVE-2020-8184", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8184", + "severity": "Medium" + }, + "CVE-2023-25193": { + "id": "CVE-2023-25193", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25193", + "severity": "High" + }, + "CVE-2022-21341": { + "id": "CVE-2022-21341", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21341", + "severity": "Low" + }, + "CVE-2020-36327": { + "id": "CVE-2020-36327", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36327", + "severity": "High" + }, + "CVE-2020-15250": { + "id": "CVE-2020-15250", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15250", + "severity": "Medium" + }, + "CVE-2023-44488": { + "id": "CVE-2023-44488", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44488", + "severity": "High" + }, + "CVE-2020-36403": { + "id": "CVE-2020-36403", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36403", + "severity": "High" + }, + "CVE-2023-39130": { + "id": "CVE-2023-39130", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39130", + "severity": "Medium" + }, + "CVE-2022-2469": { + "id": "CVE-2022-2469", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2469", + "severity": "High" + }, + "CVE-2023-27320": { + "id": "CVE-2023-27320", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27320", + "severity": "Low" + }, + "CVE-2021-33294": { + "id": "CVE-2021-33294", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33294", + "severity": "Low" + }, + "CVE-2023-5625": { + "id": "CVE-2023-5625", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5625", + "severity": "Medium" + }, + "CVE-2022-47022": { + "id": "CVE-2022-47022", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47022", + "severity": "Critical" + }, + "CVE-2023-5197": { + "id": "CVE-2023-5197", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5197", + "severity": "High" + }, + "CVE-2023-28856": { + "id": "CVE-2023-28856", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28856", + "severity": "Medium" + }, + "CVE-2024-24577": { + "id": "CVE-2024-24577", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24577", + "severity": "Critical" + }, + "CVE-2023-3648": { + "id": "CVE-2023-3648", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3648", + "severity": "Medium" + }, + "CVE-2019-2708": { + "id": "CVE-2019-2708", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-2708", + "severity": "Low" + }, + "CVE-2021-28652": { + "id": "CVE-2021-28652", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28652", + "severity": "Medium" + }, + "CVE-2022-43680": { + "id": "CVE-2022-43680", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43680", + "severity": "High" + }, + "CVE-2022-44268": { + "id": "CVE-2022-44268", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44268", + "severity": "High" + }, + "CVE-2021-35550": { + "id": "CVE-2021-35550", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35550", + "severity": "Medium" + }, + "CVE-2021-3638": { + "id": "CVE-2021-3638", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3638", + "severity": "Medium" + }, + "CVE-2023-26081": { + "id": "CVE-2023-26081", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26081", + "severity": "High" + }, + "CVE-2024-39573": { + "id": "CVE-2024-39573", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39573", + "severity": "Critical" + }, + "CVE-2022-3521": { + "id": "CVE-2022-3521", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3521", + "severity": "Medium" + }, + "CVE-2022-23094": { + "id": "CVE-2022-23094", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23094", + "severity": "High" + }, + "CVE-2024-2357": { + "id": "CVE-2024-2357", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2357", + "severity": "Low" + }, + "CVE-2023-3772": { + "id": "CVE-2023-3772", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3772", + "severity": "Medium" + }, + "CVE-2020-4030": { + "id": "CVE-2020-4030", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4030", + "severity": "Medium" + }, + "CVE-2024-3205": { + "id": "CVE-2024-3205", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3205", + "severity": "High" + }, + "CVE-2022-0330": { + "id": "CVE-2022-0330", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0330", + "severity": "Medium" + }, + "CVE-2023-42670": { + "id": "CVE-2023-42670", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42670", + "severity": "Medium" + }, + "CVE-2020-11077": { + "id": "CVE-2020-11077", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11077", + "severity": "High" + }, + "CVE-2021-27506": { + "id": "CVE-2021-27506", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27506", + "severity": "Medium" + }, + "CVE-2021-22918": { + "id": "CVE-2021-22918", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22918", + "severity": "Medium" + }, + "CVE-2023-23454": { + "id": "CVE-2023-23454", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23454", + "severity": "High" + }, + "CVE-2020-10809": { + "id": "CVE-2020-10809", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10809", + "severity": "Medium" + }, + "CVE-2021-3655": { + "id": "CVE-2021-3655", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3655", + "severity": "Medium" + }, + "CVE-2021-31812": { + "id": "CVE-2021-31812", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31812", + "severity": "Medium" + }, + "CVE-2020-8003": { + "id": "CVE-2020-8003", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8003", + "severity": "Medium" + }, + "CVE-2021-40153": { + "id": "CVE-2021-40153", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40153", + "severity": "High" + }, + "CVE-2024-24898": { + "id": "CVE-2024-24898", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24898", + "severity": "Medium" + }, + "CVE-2022-2125": { + "id": "CVE-2022-2125", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2125", + "severity": "High" + }, + "CVE-2022-2319": { + "id": "CVE-2022-2319", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2319", + "severity": "High" + }, + "CVE-2020-27756": { + "id": "CVE-2020-27756", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27756", + "severity": "Medium" + }, + "CVE-2021-25735": { + "id": "CVE-2021-25735", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25735", + "severity": "Medium" + }, + "CVE-2023-35945": { + "id": "CVE-2023-35945", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35945", + "severity": "High" + }, + "CVE-2018-1000805": { + "id": "CVE-2018-1000805", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000805", + "severity": "High" + }, + "CVE-2024-34403": { + "id": "CVE-2024-34403", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34403", + "severity": "Medium" + }, + "CVE-2023-2953": { + "id": "CVE-2023-2953", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2953", + "severity": "High" + }, + "CVE-2021-28216": { + "id": "CVE-2021-28216", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28216", + "severity": "High" + }, + "CVE-2021-20197": { + "id": "CVE-2021-20197", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20197", + "severity": "Medium" + }, + "CVE-2023-47855": { + "id": "CVE-2023-47855", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47855", + "severity": "Low" + }, + "CVE-2023-45663": { + "id": "CVE-2023-45663", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45663", + "severity": "High" + }, + "CVE-2023-32573": { + "id": "CVE-2023-32573", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32573", + "severity": "Medium" + }, + "CVE-2022-2929": { + "id": "CVE-2022-2929", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2929", + "severity": "High" + }, + "CVE-2021-20271": { + "id": "CVE-2021-20271", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20271", + "severity": "High" + }, + "CVE-2019-3825": { + "id": "CVE-2019-3825", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3825", + "severity": "Medium" + }, + "CVE-2023-42795": { + "id": "CVE-2023-42795", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42795", + "severity": "High" + }, + "CVE-2019-2692": { + "id": "CVE-2019-2692", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-2692", + "severity": "Medium" + }, + "CVE-2023-46695": { + "id": "CVE-2023-46695", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46695", + "severity": "High" + }, + "CVE-2022-3115": { + "id": "CVE-2022-3115", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3115", + "severity": "Medium" + }, + "CVE-2022-3165": { + "id": "CVE-2022-3165", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3165", + "severity": "Medium" + }, + "CVE-2022-4144": { + "id": "CVE-2022-4144", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4144", + "severity": "Medium" + }, + "CVE-2023-2610": { + "id": "CVE-2023-2610", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2610", + "severity": "High" + }, + "CVE-2022-2598": { + "id": "CVE-2022-2598", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2598", + "severity": "High" + }, + "CVE-2022-23437": { + "id": "CVE-2022-23437", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23437", + "severity": "Medium" + }, + "CVE-2020-13776": { + "id": "CVE-2020-13776", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13776", + "severity": "Medium" + }, + "CVE-2022-21505": { + "id": "CVE-2022-21505", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21505", + "severity": "Medium" + }, + "CVE-2021-44790": { + "id": "CVE-2021-44790", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44790", + "severity": "High" + }, + "CVE-2021-33632": { + "id": "CVE-2021-33632", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33632", + "severity": "High" + }, + "CVE-2021-3426": { + "id": "CVE-2021-3426", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3426", + "severity": "Medium" + }, + "CVE-2020-10688": { + "id": "CVE-2020-10688", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10688", + "severity": "Medium" + }, + "CVE-2023-23586": { + "id": "CVE-2023-23586", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23586", + "severity": "High" + }, + "CVE-2019-16370": { + "id": "CVE-2019-16370", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16370", + "severity": "Medium" + }, + "CVE-2021-46657": { + "id": "CVE-2021-46657", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46657", + "severity": "High" + }, + "CVE-2021-34432": { + "id": "CVE-2021-34432", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34432", + "severity": "High" + }, + "CVE-2021-4189": { + "id": "CVE-2021-4189", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4189", + "severity": "Medium" + }, + "CVE-2022-39348": { + "id": "CVE-2022-39348", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39348", + "severity": "High" + }, + "CVE-2021-25217": { + "id": "CVE-2021-25217", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25217", + "severity": "High" + }, + "CVE-2023-38408": { + "id": "CVE-2023-38408", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38408", + "severity": "High" + }, + "CVE-2021-20303": { + "id": "CVE-2021-20303", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20303", + "severity": "Medium" + }, + "CVE-2021-38296": { + "id": "CVE-2021-38296", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38296", + "severity": "High" + }, + "CVE-2024-6239": { + "id": "CVE-2024-6239", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6239", + "severity": "High" + }, + "CVE-2022-34903": { + "id": "CVE-2022-34903", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34903", + "severity": "Medium" + }, + "CVE-2024-29040": { + "id": "CVE-2024-29040", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29040", + "severity": "Medium" + }, + "CVE-2021-3449": { + "id": "CVE-2021-3449", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3449", + "severity": "Medium" + }, + "CVE-2022-25647": { + "id": "CVE-2022-25647", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25647", + "severity": "High" + }, + "CVE-2022-3646": { + "id": "CVE-2022-3646", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3646", + "severity": "Medium" + }, + "CVE-2022-30789": { + "id": "CVE-2022-30789", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30789", + "severity": "Critical" + }, + "CVE-2022-3108": { + "id": "CVE-2022-3108", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3108", + "severity": "Medium" + }, + "CVE-2023-47038": { + "id": "CVE-2023-47038", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47038", + "severity": "Low" + }, + "CVE-2021-45079": { + "id": "CVE-2021-45079", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45079", + "severity": "Critical" + }, + "CVE-2024-32661": { + "id": "CVE-2024-32661", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32661", + "severity": "High" + }, + "CVE-2021-20181": { + "id": "CVE-2021-20181", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20181", + "severity": "High" + }, + "CVE-2022-24769": { + "id": "CVE-2022-24769", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24769", + "severity": "Medium" + }, + "CVE-2021-44228": { + "id": "CVE-2021-44228", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228", + "severity": "High" + }, + "CVE-2022-31625": { + "id": "CVE-2022-31625", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31625", + "severity": "High" + }, + "CVE-2023-24607": { + "id": "CVE-2023-24607", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24607", + "severity": "High" + }, + "CVE-2023-34455": { + "id": "CVE-2023-34455", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34455", + "severity": "High" + }, + "CVE-2022-29154": { + "id": "CVE-2022-29154", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29154", + "severity": "High" + }, + "CVE-2024-28180": { + "id": "CVE-2024-28180", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28180", + "severity": "Medium" + }, + "CVE-2023-3341": { + "id": "CVE-2023-3341", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3341", + "severity": "High" + }, + "CVE-2023-44446": { + "id": "CVE-2023-44446", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44446", + "severity": "Medium" + }, + "CVE-2020-26572": { + "id": "CVE-2020-26572", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26572", + "severity": "Medium" + }, + "CVE-2022-41741": { + "id": "CVE-2022-41741", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41741", + "severity": "High" + }, + "CVE-2022-3554": { + "id": "CVE-2022-3554", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3554", + "severity": "High" + }, + "CVE-2020-23903": { + "id": "CVE-2020-23903", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-23903", + "severity": "Medium" + }, + "CVE-2020-10693": { + "id": "CVE-2020-10693", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10693", + "severity": "Medium" + }, + "CVE-2022-32189": { + "id": "CVE-2022-32189", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32189", + "severity": "Medium" + }, + "CVE-2023-6004": { + "id": "CVE-2023-6004", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6004", + "severity": "Medium" + }, + "CVE-2022-24958": { + "id": "CVE-2022-24958", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24958", + "severity": "High" + }, + "CVE-2021-2161": { + "id": "CVE-2021-2161", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2161", + "severity": "Medium" + }, + "CVE-2023-22742": { + "id": "CVE-2023-22742", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22742", + "severity": "Medium" + }, + "CVE-2019-14562": { + "id": "CVE-2019-14562", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14562", + "severity": "Medium" + }, + "CVE-2021-41160": { + "id": "CVE-2021-41160", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41160", + "severity": "Medium" + }, + "CVE-2020-27781": { + "id": "CVE-2020-27781", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27781", + "severity": "Medium" + }, + "CVE-2021-32765": { + "id": "CVE-2021-32765", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32765", + "severity": "High" + }, + "CVE-2019-10241": { + "id": "CVE-2019-10241", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10241", + "severity": "Medium" + }, + "CVE-2022-35414": { + "id": "CVE-2022-35414", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35414", + "severity": "High" + }, + "CVE-2020-35850": { + "id": "CVE-2020-35850", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35850", + "severity": "Medium" + }, + "CVE-2021-31292": { + "id": "CVE-2021-31292", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31292", + "severity": "Medium" + }, + "CVE-2020-25687": { + "id": "CVE-2020-25687", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25687", + "severity": "High" + }, + "CVE-2020-29385": { + "id": "CVE-2020-29385", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29385", + "severity": "High" + }, + "CVE-2021-42340": { + "id": "CVE-2021-42340", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42340", + "severity": "High" + }, + "CVE-2023-6175": { + "id": "CVE-2023-6175", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6175", + "severity": "Medium" + }, + "CVE-2021-39365": { + "id": "CVE-2021-39365", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39365", + "severity": "Medium" + }, + "CVE-2022-41973": { + "id": "CVE-2022-41973", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41973", + "severity": "High" + }, + "CVE-2024-26606": { + "id": "CVE-2024-26606", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26606", + "severity": "Low" + }, + "CVE-2023-35001": { + "id": "CVE-2023-35001", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35001", + "severity": "High" + }, + "CVE-2020-25717": { + "id": "CVE-2020-25717", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25717", + "severity": "High" + }, + "CVE-2023-28120": { + "id": "CVE-2023-28120", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28120", + "severity": "Medium" + }, + "CVE-2024-24855": { + "id": "CVE-2024-24855", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24855", + "severity": "Medium" + }, + "CVE-2021-3733": { + "id": "CVE-2021-3733", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3733", + "severity": "Medium" + }, + "CVE-2022-34835": { + "id": "CVE-2022-34835", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34835", + "severity": "Critical" + }, + "CVE-2023-28101": { + "id": "CVE-2023-28101", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28101", + "severity": "Medium" + }, + "CVE-2023-40267": { + "id": "CVE-2023-40267", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40267", + "severity": "Critical" + }, + "CVE-2023-28755": { + "id": "CVE-2023-28755", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28755", + "severity": "High" + }, + "CVE-2022-3515": { + "id": "CVE-2022-3515", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3515", + "severity": "High" + }, + "CVE-2023-1972": { + "id": "CVE-2023-1972", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1972", + "severity": "Medium" + }, + "CVE-2022-4899": { + "id": "CVE-2022-4899", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4899", + "severity": "High" + }, + "CVE-2021-38576": { + "id": "CVE-2021-38576", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38576", + "severity": "High" + }, + "CVE-2022-31213": { + "id": "CVE-2022-31213", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31213", + "severity": "High" + }, + "CVE-2022-2962": { + "id": "CVE-2022-2962", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2962", + "severity": "Medium" + }, + "CVE-2021-33098": { + "id": "CVE-2021-33098", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33098", + "severity": "Medium" + }, + "CVE-2021-32672": { + "id": "CVE-2021-32672", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32672", + "severity": "Medium" + }, + "CVE-2023-52672": { + "id": "CVE-2023-52672", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52672", + "severity": "Medium" + }, + "CVE-2024-5197": { + "id": "CVE-2024-5197", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5197", + "severity": "High" + }, + "CVE-2020-14355": { + "id": "CVE-2020-14355", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14355", + "severity": "Medium" + }, + "CVE-2023-41040": { + "id": "CVE-2023-41040", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41040", + "severity": "Medium" + }, + "CVE-2022-40023": { + "id": "CVE-2022-40023", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40023", + "severity": "High" + }, + "CVE-2024-24890": { + "id": "CVE-2024-24890", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24890", + "severity": "High" + }, + "CVE-2023-2426": { + "id": "CVE-2023-2426", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2426", + "severity": "Medium" + }, + "CVE-2021-0326": { + "id": "CVE-2021-0326", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0326", + "severity": "High" + }, + "CVE-2022-21233": { + "id": "CVE-2022-21233", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21233", + "severity": "Medium" + }, + "CVE-2023-50868": { + "id": "CVE-2023-50868", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50868", + "severity": "High" + }, + "CVE-2022-47629": { + "id": "CVE-2022-47629", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47629", + "severity": "Medium" + }, + "CVE-2021-27918": { + "id": "CVE-2021-27918", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27918", + "severity": "High" + }, + "CVE-2021-3504": { + "id": "CVE-2021-3504", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3504", + "severity": "High" + }, + "CVE-2021-33655": { + "id": "CVE-2021-33655", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33655", + "severity": "Medium" + }, + "CVE-2022-3517": { + "id": "CVE-2022-3517", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3517", + "severity": "High" + }, + "CVE-2022-2585": { + "id": "CVE-2022-2585", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2585", + "severity": "High" + }, + "CVE-2023-32697": { + "id": "CVE-2023-32697", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32697", + "severity": "Critical" + }, + "CVE-2023-0614": { + "id": "CVE-2023-0614", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0614", + "severity": "Medium" + }, + "CVE-2021-43618": { + "id": "CVE-2021-43618", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43618", + "severity": "High" + }, + "CVE-2021-33061": { + "id": "CVE-2021-33061", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33061", + "severity": "Medium" + }, + "CVE-2024-25617": { + "id": "CVE-2024-25617", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25617", + "severity": "Medium" + }, + "CVE-2020-26570": { + "id": "CVE-2020-26570", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26570", + "severity": "Medium" + }, + "CVE-2023-43641": { + "id": "CVE-2023-43641", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43641", + "severity": "High" + }, + "CVE-2022-3190": { + "id": "CVE-2022-3190", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3190", + "severity": "Medium" + }, + "CVE-2023-5366": { + "id": "CVE-2023-5366", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5366", + "severity": "High" + }, + "CVE-2023-51385": { + "id": "CVE-2023-51385", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51385", + "severity": "Critical" + }, + "CVE-2021-3421": { + "id": "CVE-2021-3421", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3421", + "severity": "Medium" + }, + "CVE-2021-21707": { + "id": "CVE-2021-21707", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21707", + "severity": "Medium" + }, + "CVE-2022-34169": { + "id": "CVE-2022-34169", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34169", + "severity": "Medium" + }, + "CVE-2022-2602": { + "id": "CVE-2022-2602", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2602", + "severity": "Medium" + }, + "CVE-2024-6387": { + "id": "CVE-2024-6387", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6387", + "severity": "High" + }, + "CVE-2022-1886": { + "id": "CVE-2022-1886", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1886", + "severity": "Critical" + }, + "CVE-2021-20095": { + "id": "CVE-2021-20095", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20095", + "severity": "High" + }, + "CVE-2023-32233": { + "id": "CVE-2023-32233", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32233", + "severity": "Medium" + }, + "CVE-2020-18770": { + "id": "CVE-2020-18770", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-18770", + "severity": "Medium" + }, + "CVE-2021-46822": { + "id": "CVE-2021-46822", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46822", + "severity": "Medium" + }, + "CVE-2022-32250": { + "id": "CVE-2022-32250", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32250", + "severity": "Medium" + }, + "CVE-2022-24882": { + "id": "CVE-2022-24882", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24882", + "severity": "Critical" + }, + "CVE-2023-6915": { + "id": "CVE-2023-6915", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6915", + "severity": "High" + }, + "CVE-2022-1115": { + "id": "CVE-2022-1115", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1115", + "severity": "Medium" + }, + "CVE-2022-32148": { + "id": "CVE-2022-32148", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32148", + "severity": "Medium" + }, + "CVE-2021-30640": { + "id": "CVE-2021-30640", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30640", + "severity": "Medium" + }, + "CVE-2021-44227": { + "id": "CVE-2021-44227", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44227", + "severity": "High" + }, + "CVE-2023-42366": { + "id": "CVE-2023-42366", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42366", + "severity": "Medium" + }, + "CVE-2022-31799": { + "id": "CVE-2022-31799", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31799", + "severity": "Critical" + }, + "CVE-2024-38661": { + "id": "CVE-2024-38661", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38661", + "severity": "High" + }, + "CVE-2024-24259": { + "id": "CVE-2024-24259", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24259", + "severity": "High" + }, + "CVE-2023-29409": { + "id": "CVE-2023-29409", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29409", + "severity": "Medium" + }, + "CVE-2021-20257": { + "id": "CVE-2021-20257", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20257", + "severity": "Medium" + }, + "CVE-2021-41099": { + "id": "CVE-2021-41099", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41099", + "severity": "High" + }, + "CVE-2024-21626": { + "id": "CVE-2024-21626", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21626", + "severity": "High" + }, + "CVE-2022-21271": { + "id": "CVE-2022-21271", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21271", + "severity": "Medium" + }, + "CVE-2023-46218": { + "id": "CVE-2023-46218", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46218", + "severity": "Medium" + }, + "CVE-2020-13867": { + "id": "CVE-2020-13867", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13867", + "severity": "Medium" + }, + "CVE-2023-26253": { + "id": "CVE-2023-26253", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26253", + "severity": "High" + }, + "CVE-2019-12402": { + "id": "CVE-2019-12402", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12402", + "severity": "Critical" + }, + "CVE-2020-12658": { + "id": "CVE-2020-12658", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12658", + "severity": "Critical" + }, + "CVE-2020-12863": { + "id": "CVE-2020-12863", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12863", + "severity": "Medium" + }, + "CVE-2020-9492": { + "id": "CVE-2020-9492", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9492", + "severity": "High" + }, + "CVE-2024-34064": { + "id": "CVE-2024-34064", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34064", + "severity": "Medium" + }, + "CVE-2021-3326": { + "id": "CVE-2021-3326", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3326", + "severity": "Medium" + }, + "CVE-2023-6931": { + "id": "CVE-2023-6931", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6931", + "severity": "Medium" + }, + "CVE-2022-24999": { + "id": "CVE-2022-24999", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24999", + "severity": "High" + }, + "CVE-2021-22570": { + "id": "CVE-2021-22570", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22570", + "severity": "High" + }, + "CVE-2021-2160": { + "id": "CVE-2021-2160", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2160", + "severity": "Medium" + }, + "CVE-2019-17362": { + "id": "CVE-2019-17362", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17362", + "severity": "Critical" + }, + "CVE-2021-20289": { + "id": "CVE-2021-20289", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20289", + "severity": "Medium" + }, + "CVE-2021-39272": { + "id": "CVE-2021-39272", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39272", + "severity": "Medium" + }, + "CVE-2023-43907": { + "id": "CVE-2023-43907", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43907", + "severity": "High" + }, + "CVE-2021-29478": { + "id": "CVE-2021-29478", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29478", + "severity": "High" + }, + "CVE-2021-4213": { + "id": "CVE-2021-4213", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4213", + "severity": "High" + }, + "CVE-2024-37535": { + "id": "CVE-2024-37535", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37535", + "severity": "Low" + }, + "CVE-2018-2799": { + "id": "CVE-2018-2799", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-2799", + "severity": "Medium" + }, + "CVE-2023-38546": { + "id": "CVE-2023-38546", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38546", + "severity": "High" + }, + "CVE-2015-1197": { + "id": "CVE-2015-1197", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1197", + "severity": "Low" + }, + "CVE-2020-7069": { + "id": "CVE-2020-7069", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7069", + "severity": "Critical" + }, + "CVE-2020-25654": { + "id": "CVE-2020-25654", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25654", + "severity": "High" + }, + "CVE-2021-32142": { + "id": "CVE-2021-32142", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32142", + "severity": "High" + }, + "CVE-2021-40812": { + "id": "CVE-2021-40812", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40812", + "severity": "Medium" + }, + "CVE-2023-31147": { + "id": "CVE-2023-31147", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31147", + "severity": "Medium" + }, + "CVE-2023-29403": { + "id": "CVE-2023-29403", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29403", + "severity": "High" + }, + "CVE-2020-24455": { + "id": "CVE-2020-24455", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24455", + "severity": "Medium" + }, + "CVE-2022-30522": { + "id": "CVE-2022-30522", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30522", + "severity": "Medium" + }, + "CVE-2023-6681": { + "id": "CVE-2023-6681", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6681", + "severity": "Medium" + }, + "CVE-2020-14093": { + "id": "CVE-2020-14093", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14093", + "severity": "Medium" + }, + "CVE-2023-50967": { + "id": "CVE-2023-50967", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50967", + "severity": "Low" + }, + "CVE-2022-4904": { + "id": "CVE-2022-4904", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4904", + "severity": "Medium" + }, + "CVE-2021-38198": { + "id": "CVE-2021-38198", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38198", + "severity": "Medium" + }, + "CVE-2022-1852": { + "id": "CVE-2022-1852", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1852", + "severity": "Medium" + }, + "CVE-2021-46143": { + "id": "CVE-2021-46143", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46143", + "severity": "High" + }, + "CVE-2023-3316": { + "id": "CVE-2023-3316", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3316", + "severity": "High" + }, + "CVE-2020-25648": { + "id": "CVE-2020-25648", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25648", + "severity": "Medium" + }, + "CVE-2024-22705": { + "id": "CVE-2024-22705", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22705", + "severity": "Medium" + }, + "CVE-2020-15103": { + "id": "CVE-2020-15103", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15103", + "severity": "Low" + }, + "CVE-2021-40438": { + "id": "CVE-2021-40438", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40438", + "severity": "High" + }, + "CVE-2021-23362": { + "id": "CVE-2021-23362", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23362", + "severity": "Medium" + }, + "CVE-2020-27821": { + "id": "CVE-2020-27821", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27821", + "severity": "Medium" + }, + "CVE-2022-20368": { + "id": "CVE-2022-20368", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20368", + "severity": "Critical" + }, + "CVE-2023-37327": { + "id": "CVE-2023-37327", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37327", + "severity": "Medium" + }, + "CVE-2023-51781": { + "id": "CVE-2023-51781", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51781", + "severity": "High" + }, + "CVE-2021-2301": { + "id": "CVE-2021-2301", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2301", + "severity": "Medium" + }, + "CVE-2023-34969": { + "id": "CVE-2023-34969", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34969", + "severity": "Medium" + }, + "CVE-2023-2908": { + "id": "CVE-2023-2908", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2908", + "severity": "Medium" + }, + "CVE-2022-2806": { + "id": "CVE-2022-2806", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2806", + "severity": "Medium" + }, + "CVE-2021-44040": { + "id": "CVE-2021-44040", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44040", + "severity": "High" + }, + "CVE-2021-45463": { + "id": "CVE-2021-45463", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45463", + "severity": "High" + }, + "CVE-2023-24534": { + "id": "CVE-2023-24534", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24534", + "severity": "High" + }, + "CVE-2020-10650": { + "id": "CVE-2020-10650", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10650", + "severity": "High" + }, + "CVE-2021-28861": { + "id": "CVE-2021-28861", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28861", + "severity": "High" + }, + "CVE-2022-36227": { + "id": "CVE-2022-36227", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36227", + "severity": "Critical" + }, + "CVE-2022-23648": { + "id": "CVE-2022-23648", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23648", + "severity": "High" + }, + "CVE-2023-4693": { + "id": "CVE-2023-4693", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4693", + "severity": "High" + }, + "CVE-2023-22795": { + "id": "CVE-2023-22795", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22795", + "severity": "High" + }, + "CVE-2021-42739": { + "id": "CVE-2021-42739", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42739", + "severity": "Medium" + }, + "CVE-2022-0135": { + "id": "CVE-2022-0135", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0135", + "severity": "High" + }, + "CVE-2023-24626": { + "id": "CVE-2023-24626", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24626", + "severity": "Medium" + }, + "CVE-2023-28486": { + "id": "CVE-2023-28486", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28486", + "severity": "Medium" + }, + "CVE-2021-40633": { + "id": "CVE-2021-40633", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40633", + "severity": "High" + }, + "CVE-2022-24834": { + "id": "CVE-2022-24834", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24834", + "severity": "High" + }, + "CVE-2022-24052": { + "id": "CVE-2022-24052", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24052", + "severity": "High" + }, + "CVE-2024-32465": { + "id": "CVE-2024-32465", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32465", + "severity": "Critical" + }, + "CVE-2024-27281": { + "id": "CVE-2024-27281", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27281", + "severity": "Low" + }, + "CVE-2022-21724": { + "id": "CVE-2022-21724", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21724", + "severity": "High" + }, + "CVE-2022-24836": { + "id": "CVE-2022-24836", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24836", + "severity": "High" + }, + "CVE-2022-4064": { + "id": "CVE-2022-4064", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4064", + "severity": "Low" + }, + "CVE-2022-4842": { + "id": "CVE-2022-4842", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4842", + "severity": "High" + }, + "CVE-2021-29509": { + "id": "CVE-2021-29509", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29509", + "severity": "High" + }, + "CVE-2021-38575": { + "id": "CVE-2021-38575", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38575", + "severity": "High" + }, + "CVE-2020-13848": { + "id": "CVE-2020-13848", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13848", + "severity": "High" + }, + "CVE-2021-3715": { + "id": "CVE-2021-3715", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3715", + "severity": "High" + }, + "CVE-2019-17544": { + "id": "CVE-2019-17544", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17544", + "severity": "Critical" + }, + "CVE-2021-36370": { + "id": "CVE-2021-36370", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36370", + "severity": "High" + }, + "CVE-2021-41103": { + "id": "CVE-2021-41103", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41103", + "severity": "High" + }, + "CVE-2021-3445": { + "id": "CVE-2021-3445", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3445", + "severity": "High" + }, + "CVE-2021-21240": { + "id": "CVE-2021-21240", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21240", + "severity": "High" + }, + "CVE-2021-22926": { + "id": "CVE-2021-22926", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22926", + "severity": "Low" + }, + "CVE-2021-20270": { + "id": "CVE-2021-20270", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20270", + "severity": "High" + }, + "CVE-2020-25657": { + "id": "CVE-2020-25657", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25657", + "severity": "Medium" + }, + "CVE-2021-33621": { + "id": "CVE-2021-33621", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33621", + "severity": "High" + }, + "CVE-2022-43995": { + "id": "CVE-2022-43995", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43995", + "severity": "High" + }, + "CVE-2023-22745": { + "id": "CVE-2023-22745", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22745", + "severity": "Medium" + }, + "CVE-2021-47401": { + "id": "CVE-2021-47401", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47401", + "severity": "Medium" + }, + "CVE-2022-45934": { + "id": "CVE-2022-45934", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45934", + "severity": "High" + }, + "CVE-2023-45675": { + "id": "CVE-2023-45675", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45675", + "severity": "High" + }, + "CVE-2023-51782": { + "id": "CVE-2023-51782", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51782", + "severity": "Medium" + }, + "CVE-2021-3622": { + "id": "CVE-2021-3622", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3622", + "severity": "Medium" + }, + "CVE-2021-33910": { + "id": "CVE-2021-33910", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33910", + "severity": "Medium" + }, + "CVE-2019-18281": { + "id": "CVE-2019-18281", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18281", + "severity": "Medium" + }, + "CVE-2022-21702": { + "id": "CVE-2022-21702", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21702", + "severity": "Medium" + }, + "CVE-2022-39399": { + "id": "CVE-2022-39399", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39399", + "severity": "Medium" + }, + "CVE-2019-20433": { + "id": "CVE-2019-20433", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20433", + "severity": "Medium" + }, + "CVE-2024-2398": { + "id": "CVE-2024-2398", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2398", + "severity": "Medium" + }, + "CVE-2022-20698": { + "id": "CVE-2022-20698", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20698", + "severity": "High" + }, + "CVE-2023-34059": { + "id": "CVE-2023-34059", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34059", + "severity": "High" + }, + "CVE-2024-28219": { + "id": "CVE-2024-28219", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28219", + "severity": "Medium" + }, + "CVE-2021-33639": { + "id": "CVE-2021-33639", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33639", + "severity": "Medium" + }, + "CVE-2023-41164": { + "id": "CVE-2023-41164", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41164", + "severity": "Medium" + }, + "CVE-2023-3301": { + "id": "CVE-2023-3301", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3301", + "severity": "Medium" + }, + "CVE-2022-45141": { + "id": "CVE-2022-45141", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45141", + "severity": "High" + }, + "CVE-2021-46142": { + "id": "CVE-2021-46142", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46142", + "severity": "Medium" + }, + "CVE-2022-3424": { + "id": "CVE-2022-3424", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3424", + "severity": "Medium" + }, + "CVE-2022-40090": { + "id": "CVE-2022-40090", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40090", + "severity": "Medium" + }, + "CVE-2022-1355": { + "id": "CVE-2022-1355", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1355", + "severity": "High" + }, + "CVE-2023-6932": { + "id": "CVE-2023-6932", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6932", + "severity": "Medium" + }, + "CVE-2022-3256": { + "id": "CVE-2022-3256", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3256", + "severity": "High" + }, + "CVE-2021-3517": { + "id": "CVE-2021-3517", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3517", + "severity": "Medium" + }, + "CVE-2021-45046": { + "id": "CVE-2021-45046", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45046", + "severity": "Critical" + }, + "CVE-2021-20203": { + "id": "CVE-2021-20203", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20203", + "severity": "Medium" + }, + "CVE-2024-1013": { + "id": "CVE-2024-1013", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1013", + "severity": "High" + }, + "CVE-2023-33461": { + "id": "CVE-2023-33461", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33461", + "severity": "Medium" + }, + "CVE-2021-3572": { + "id": "CVE-2021-3572", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3572", + "severity": "Medium" + }, + "CVE-2022-45059": { + "id": "CVE-2022-45059", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45059", + "severity": "High" + }, + "CVE-2020-35518": { + "id": "CVE-2020-35518", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35518", + "severity": "Medium" + }, + "CVE-2020-35492": { + "id": "CVE-2020-35492", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35492", + "severity": "High" + }, + "CVE-2023-0667": { + "id": "CVE-2023-0667", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0667", + "severity": "Medium" + }, + "CVE-2021-44832": { + "id": "CVE-2021-44832", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44832", + "severity": "High" + }, + "CVE-2024-0607": { + "id": "CVE-2024-0607", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0607", + "severity": "High" + }, + "CVE-2019-10156": { + "id": "CVE-2019-10156", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10156", + "severity": "Medium" + }, + "CVE-2017-12596": { + "id": "CVE-2017-12596", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12596", + "severity": "Medium" + }, + "CVE-2020-28196": { + "id": "CVE-2020-28196", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28196", + "severity": "High" + }, + "CVE-2023-25950": { + "id": "CVE-2023-25950", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25950", + "severity": "Critical" + }, + "CVE-2022-48281": { + "id": "CVE-2022-48281", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48281", + "severity": "High" + }, + "CVE-2023-43642": { + "id": "CVE-2023-43642", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43642", + "severity": "High" + }, + "CVE-2023-24805": { + "id": "CVE-2023-24805", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24805", + "severity": "High" + }, + "CVE-2019-7575": { + "id": "CVE-2019-7575", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7575", + "severity": "High" + }, + "CVE-2022-1215": { + "id": "CVE-2022-1215", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1215", + "severity": "High" + }, + "CVE-2020-27837": { + "id": "CVE-2020-27837", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27837", + "severity": "Medium" + }, + "CVE-2021-3605": { + "id": "CVE-2021-3605", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3605", + "severity": "Medium" + }, + "CVE-2023-1436": { + "id": "CVE-2023-1436", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1436", + "severity": "High" + }, + "CVE-2023-35789": { + "id": "CVE-2023-35789", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35789", + "severity": "Medium" + }, + "CVE-2021-3560": { + "id": "CVE-2021-3560", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3560", + "severity": "High" + }, + "CVE-2020-25713": { + "id": "CVE-2020-25713", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25713", + "severity": "Medium" + }, + "CVE-2020-14001": { + "id": "CVE-2020-14001", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14001", + "severity": "Critical" + }, + "CVE-2023-1906": { + "id": "CVE-2023-1906", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1906", + "severity": "Medium" + }, + "CVE-2023-39410": { + "id": "CVE-2023-39410", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39410", + "severity": "High" + }, + "CVE-2022-2588": { + "id": "CVE-2022-2588", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2588", + "severity": "Medium" + }, + "CVE-2023-6693": { + "id": "CVE-2023-6693", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6693", + "severity": "Medium" + }, + "CVE-2022-1348": { + "id": "CVE-2022-1348", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1348", + "severity": "Medium" + }, + "CVE-2023-42753": { + "id": "CVE-2023-42753", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42753", + "severity": "High" + }, + "CVE-2024-1488": { + "id": "CVE-2024-1488", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1488", + "severity": "High" + }, + "CVE-2024-35930": { + "id": "CVE-2024-35930", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35930", + "severity": "Medium" + }, + "CVE-2022-44792": { + "id": "CVE-2022-44792", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44792", + "severity": "Medium" + }, + "CVE-2020-28163": { + "id": "CVE-2020-28163", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28163", + "severity": "Medium" + }, + "CVE-2023-4513": { + "id": "CVE-2023-4513", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4513", + "severity": "Medium" + }, + "CVE-2021-28041": { + "id": "CVE-2021-28041", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28041", + "severity": "High" + }, + "CVE-2022-41974": { + "id": "CVE-2022-41974", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41974", + "severity": "High" + }, + "CVE-2024-27316": { + "id": "CVE-2024-27316", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27316", + "severity": "Medium" + }, + "CVE-2021-3700": { + "id": "CVE-2021-3700", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3700", + "severity": "Low" + }, + "CVE-2021-37501": { + "id": "CVE-2021-37501", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37501", + "severity": "Medium" + }, + "CVE-2021-39151": { + "id": "CVE-2021-39151", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39151", + "severity": "High" + }, + "CVE-2022-21322": { + "id": "CVE-2022-21322", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21322", + "severity": "Medium" + }, + "CVE-2024-0911": { + "id": "CVE-2024-0911", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0911", + "severity": "Medium" + }, + "CVE-2023-1161": { + "id": "CVE-2023-1161", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1161", + "severity": "High" + }, + "CVE-2022-3586": { + "id": "CVE-2022-3586", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3586", + "severity": "Medium" + }, + "CVE-2021-4115": { + "id": "CVE-2021-4115", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4115", + "severity": "Medium" + }, + "CVE-2020-36774": { + "id": "CVE-2020-36774", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36774", + "severity": "Medium" + }, + "CVE-2024-24790": { + "id": "CVE-2024-24790", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24790", + "severity": "Critical" + }, + "CVE-2023-3358": { + "id": "CVE-2023-3358", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3358", + "severity": "High" + }, + "CVE-2022-2047": { + "id": "CVE-2022-2047", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2047", + "severity": "High" + }, + "CVE-2020-23064": { + "id": "CVE-2020-23064", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-23064", + "severity": "Medium" + }, + "CVE-2022-1664": { + "id": "CVE-2022-1664", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1664", + "severity": "Medium" + }, + "CVE-2023-45648": { + "id": "CVE-2023-45648", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45648", + "severity": "Medium" + }, + "CVE-2021-25219": { + "id": "CVE-2021-25219", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25219", + "severity": "Medium" + }, + "CVE-2021-43331": { + "id": "CVE-2021-43331", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43331", + "severity": "Medium" + }, + "CVE-2024-30156": { + "id": "CVE-2024-30156", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30156", + "severity": "High" + }, + "CVE-2020-0499": { + "id": "CVE-2020-0499", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0499", + "severity": "Medium" + }, + "CVE-2024-26583": { + "id": "CVE-2024-26583", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26583", + "severity": "High" + }, + "CVE-2023-45288": { + "id": "CVE-2023-45288", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45288", + "severity": "High" + }, + "CVE-2022-0617": { + "id": "CVE-2022-0617", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0617", + "severity": "Medium" + }, + "CVE-2021-3918": { + "id": "CVE-2021-3918", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3918", + "severity": "Medium" + }, + "CVE-2022-28327": { + "id": "CVE-2022-28327", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28327", + "severity": "Medium" + }, + "CVE-2020-25690": { + "id": "CVE-2020-25690", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25690", + "severity": "High" + }, + "CVE-2021-2163": { + "id": "CVE-2021-2163", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2163", + "severity": "Medium" + }, + "CVE-2021-33640": { + "id": "CVE-2021-33640", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33640", + "severity": "Medium" + }, + "CVE-2020-7729": { + "id": "CVE-2020-7729", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7729", + "severity": "High" + }, + "CVE-2022-0396": { + "id": "CVE-2022-0396", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0396", + "severity": "Medium" + }, + "CVE-2023-52868": { + "id": "CVE-2023-52868", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52868", + "severity": "Low" + }, + "CVE-2024-4854": { + "id": "CVE-2024-4854", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4854", + "severity": "Medium" + }, + "CVE-2024-3596": { + "id": "CVE-2024-3596", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3596", + "severity": "High" + }, + "CVE-2022-38266": { + "id": "CVE-2022-38266", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38266", + "severity": "Medium" + }, + "CVE-2021-22543": { + "id": "CVE-2021-22543", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22543", + "severity": "High" + }, + "CVE-2007-4559": { + "id": "CVE-2007-4559", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-4559", + "severity": "Medium" + }, + "CVE-2020-24165": { + "id": "CVE-2020-24165", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24165", + "severity": "Medium" + }, + "CVE-2023-28625": { + "id": "CVE-2023-28625", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28625", + "severity": "Medium" + }, + "CVE-2022-48522": { + "id": "CVE-2022-48522", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48522", + "severity": "Medium" + }, + "CVE-2024-23301": { + "id": "CVE-2024-23301", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23301", + "severity": "High" + }, + "CVE-2022-45406": { + "id": "CVE-2022-45406", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45406", + "severity": "High" + }, + "CVE-2020-27153": { + "id": "CVE-2020-27153", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27153", + "severity": "High" + }, + "CVE-2022-3171": { + "id": "CVE-2022-3171", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3171", + "severity": "High" + }, + "CVE-2021-42384": { + "id": "CVE-2021-42384", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42384", + "severity": "High" + }, + "CVE-2023-28708": { + "id": "CVE-2023-28708", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28708", + "severity": "Medium" + }, + "CVE-2021-3658": { + "id": "CVE-2021-3658", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3658", + "severity": "Medium" + }, + "CVE-2021-30465": { + "id": "CVE-2021-30465", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30465", + "severity": "High" + }, + "CVE-2023-29491": { + "id": "CVE-2023-29491", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29491", + "severity": "High" + }, + "CVE-2023-38403": { + "id": "CVE-2023-38403", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38403", + "severity": "Medium" + }, + "CVE-2021-2032": { + "id": "CVE-2021-2032", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2032", + "severity": "Medium" + }, + "CVE-2021-3505": { + "id": "CVE-2021-3505", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3505", + "severity": "Medium" + }, + "CVE-2021-3929": { + "id": "CVE-2021-3929", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3929", + "severity": "High" + }, + "CVE-2024-35849": { + "id": "CVE-2024-35849", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35849", + "severity": "Medium" + }, + "CVE-2020-29050": { + "id": "CVE-2020-29050", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29050", + "severity": "High" + }, + "CVE-2021-23926": { + "id": "CVE-2021-23926", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23926", + "severity": "Critical" + }, + "CVE-2019-25013": { + "id": "CVE-2019-25013", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25013", + "severity": "Medium" + }, + "CVE-2024-32230": { + "id": "CVE-2024-32230", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32230", + "severity": "Medium" + }, + "CVE-2022-28347": { + "id": "CVE-2022-28347", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28347", + "severity": "Critical" + }, + "CVE-2023-45853": { + "id": "CVE-2023-45853", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45853", + "severity": "Critical" + }, + "CVE-2021-42374": { + "id": "CVE-2021-42374", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42374", + "severity": "Critical" + }, + "CVE-2022-41716": { + "id": "CVE-2022-41716", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41716", + "severity": "High" + }, + "CVE-2021-32627": { + "id": "CVE-2021-32627", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32627", + "severity": "High" + }, + "CVE-2022-0670": { + "id": "CVE-2022-0670", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0670", + "severity": "Critical" + }, + "CVE-2022-20423": { + "id": "CVE-2022-20423", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20423", + "severity": "Medium" + }, + "CVE-2024-24680": { + "id": "CVE-2024-24680", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24680", + "severity": "High" + }, + "CVE-2021-29922": { + "id": "CVE-2021-29922", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29922", + "severity": "Critical" + }, + "CVE-2021-27845": { + "id": "CVE-2021-27845", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27845", + "severity": "Medium" + }, + "CVE-2021-3750": { + "id": "CVE-2021-3750", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3750", + "severity": "High" + }, + "CVE-2022-41725": { + "id": "CVE-2022-41725", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41725", + "severity": "High" + }, + "CVE-2022-42721": { + "id": "CVE-2022-42721", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42721", + "severity": "Medium" + }, + "CVE-2022-0711": { + "id": "CVE-2022-0711", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0711", + "severity": "High" + }, + "CVE-2023-47641": { + "id": "CVE-2023-47641", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47641", + "severity": "Low" + }, + "CVE-2021-45444": { + "id": "CVE-2021-45444", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45444", + "severity": "High" + }, + "CVE-2022-2058": { + "id": "CVE-2022-2058", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2058", + "severity": "Medium" + }, + "CVE-2021-47372": { + "id": "CVE-2021-47372", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47372", + "severity": "Medium" + }, + "CVE-2024-28834": { + "id": "CVE-2024-28834", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28834", + "severity": "Medium" + }, + "CVE-2016-9843": { + "id": "CVE-2016-9843", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9843", + "severity": "High" + }, + "CVE-2021-3621": { + "id": "CVE-2021-3621", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3621", + "severity": "Medium" + }, + "CVE-2022-2414": { + "id": "CVE-2022-2414", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2414", + "severity": "High" + }, + "CVE-2022-36021": { + "id": "CVE-2022-36021", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36021", + "severity": "Medium" + }, + "CVE-2022-41409": { + "id": "CVE-2022-41409", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41409", + "severity": "High" + }, + "CVE-2022-47015": { + "id": "CVE-2022-47015", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47015", + "severity": "High" + }, + "CVE-2023-3164": { + "id": "CVE-2023-3164", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3164", + "severity": "Medium" + }, + "CVE-2021-0129": { + "id": "CVE-2021-0129", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0129", + "severity": "Critical" + }, + "CVE-2024-36940": { + "id": "CVE-2024-36940", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36940", + "severity": "Medium" + }, + "CVE-2022-40897": { + "id": "CVE-2022-40897", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40897", + "severity": "High" + }, + "CVE-2023-39929": { + "id": "CVE-2023-39929", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39929", + "severity": "Medium" + }, + "CVE-2023-43787": { + "id": "CVE-2023-43787", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43787", + "severity": "Medium" + }, + "CVE-2022-0897": { + "id": "CVE-2022-0897", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0897", + "severity": "Medium" + }, + "CVE-2022-1271": { + "id": "CVE-2022-1271", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1271", + "severity": "High" + }, + "CVE-2018-3848": { + "id": "CVE-2018-3848", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-3848", + "severity": "High" + }, + "CVE-2023-37920": { + "id": "CVE-2023-37920", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37920", + "severity": "High" + }, + "CVE-2020-21687": { + "id": "CVE-2020-21687", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-21687", + "severity": "Medium" + }, + "CVE-2022-24614": { + "id": "CVE-2022-24614", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24614", + "severity": "Medium" + }, + "CVE-2023-1672": { + "id": "CVE-2023-1672", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1672", + "severity": "Medium" + }, + "CVE-2021-32626": { + "id": "CVE-2021-32626", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32626", + "severity": "High" + }, + "CVE-2019-12779": { + "id": "CVE-2019-12779", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12779", + "severity": "High" + }, + "CVE-2020-15025": { + "id": "CVE-2020-15025", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15025", + "severity": "Medium" + }, + "CVE-2022-30767": { + "id": "CVE-2022-30767", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30767", + "severity": "Critical" + }, + "CVE-2021-3770": { + "id": "CVE-2021-3770", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3770", + "severity": "High" + }, + "CVE-2020-26965": { + "id": "CVE-2020-26965", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26965", + "severity": "Medium" + }, + "CVE-2020-24386": { + "id": "CVE-2020-24386", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24386", + "severity": "High" + }, + "CVE-2022-40768": { + "id": "CVE-2022-40768", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40768", + "severity": "Medium" + }, + "CVE-2023-52452": { + "id": "CVE-2023-52452", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52452", + "severity": "Medium" + }, + "CVE-2020-11736": { + "id": "CVE-2020-11736", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11736", + "severity": "Low" + }, + "CVE-2022-29167": { + "id": "CVE-2022-29167", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29167", + "severity": "High" + }, + "CVE-2021-32066": { + "id": "CVE-2021-32066", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32066", + "severity": "High" + }, + "CVE-2021-33634": { + "id": "CVE-2021-33634", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33634", + "severity": "Medium" + }, + "CVE-2021-3181": { + "id": "CVE-2021-3181", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3181", + "severity": "Medium" + }, + "CVE-2022-38023": { + "id": "CVE-2022-38023", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38023", + "severity": "High" + }, + "CVE-2024-26825": { + "id": "CVE-2024-26825", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26825", + "severity": "Medium" + }, + "CVE-2022-24839": { + "id": "CVE-2022-24839", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24839", + "severity": "High" + }, + "CVE-2023-5178": { + "id": "CVE-2023-5178", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5178", + "severity": "Medium" + }, + "CVE-2023-4785": { + "id": "CVE-2023-4785", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4785", + "severity": "High" + }, + "CVE-2023-2879": { + "id": "CVE-2023-2879", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2879", + "severity": "High" + }, + "CVE-2021-3479": { + "id": "CVE-2021-3479", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3479", + "severity": "Medium" + }, + "CVE-2023-2856": { + "id": "CVE-2023-2856", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2856", + "severity": "Medium" + }, + "CVE-2023-0687": { + "id": "CVE-2023-0687", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0687", + "severity": "Critical" + }, + "CVE-2022-24736": { + "id": "CVE-2022-24736", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24736", + "severity": "High" + }, + "CVE-2022-48566": { + "id": "CVE-2022-48566", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48566", + "severity": "High" + }, + "CVE-2022-39282": { + "id": "CVE-2022-39282", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39282", + "severity": "High" + }, + "CVE-2023-36617": { + "id": "CVE-2023-36617", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36617", + "severity": "Medium" + }, + "CVE-2021-28965": { + "id": "CVE-2021-28965", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28965", + "severity": "High" + }, + "CVE-2022-28199": { + "id": "CVE-2022-28199", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28199", + "severity": "High" + }, + "CVE-2021-37600": { + "id": "CVE-2021-37600", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37600", + "severity": "Critical" + }, + "CVE-2020-14422": { + "id": "CVE-2020-14422", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14422", + "severity": "High" + }, + "CVE-2022-1735": { + "id": "CVE-2022-1735", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1735", + "severity": "High" + }, + "CVE-2021-3660": { + "id": "CVE-2021-3660", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3660", + "severity": "Low" + }, + "CVE-2020-15169": { + "id": "CVE-2020-15169", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15169", + "severity": "Medium" + }, + "CVE-2022-1011": { + "id": "CVE-2022-1011", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1011", + "severity": "High" + }, + "CVE-2022-36879": { + "id": "CVE-2022-36879", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36879", + "severity": "Medium" + }, + "CVE-2023-22045": { + "id": "CVE-2023-22045", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22045", + "severity": "Medium" + }, + "CVE-2024-0690": { + "id": "CVE-2024-0690", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0690", + "severity": "Medium" + }, + "CVE-2021-3246": { + "id": "CVE-2021-3246", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3246", + "severity": "High" + }, + "CVE-2022-39320": { + "id": "CVE-2022-39320", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39320", + "severity": "Critical" + }, + "CVE-2022-32547": { + "id": "CVE-2022-32547", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32547", + "severity": "High" + }, + "CVE-2022-3756": { + "id": "CVE-2022-3756", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3756", + "severity": "High" + }, + "CVE-2022-0685": { + "id": "CVE-2022-0685", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0685", + "severity": "High" + }, + "CVE-2023-46246": { + "id": "CVE-2023-46246", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46246", + "severity": "Low" + }, + "CVE-2023-0394": { + "id": "CVE-2023-0394", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0394", + "severity": "Medium" + }, + "CVE-2019-18853": { + "id": "CVE-2019-18853", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18853", + "severity": "Low" + }, + "CVE-2020-7062": { + "id": "CVE-2020-7062", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7062", + "severity": "High" + }, + "CVE-2024-0553": { + "id": "CVE-2024-0553", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0553", + "severity": "Medium" + }, + "CVE-2021-3468": { + "id": "CVE-2021-3468", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3468", + "severity": "Medium" + }, + "CVE-2022-24302": { + "id": "CVE-2022-24302", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24302", + "severity": "Medium" + }, + "CVE-2021-30129": { + "id": "CVE-2021-30129", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30129", + "severity": "Medium" + }, + "CVE-2022-30630": { + "id": "CVE-2022-30630", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30630", + "severity": "Medium" + }, + "CVE-2019-12293": { + "id": "CVE-2019-12293", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12293", + "severity": "High" + }, + "CVE-2023-32324": { + "id": "CVE-2023-32324", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32324", + "severity": "High" + }, + "CVE-2019-14822": { + "id": "CVE-2019-14822", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14822", + "severity": "High" + }, + "CVE-2021-36217": { + "id": "CVE-2021-36217", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36217", + "severity": "Medium" + }, + "CVE-2021-22945": { + "id": "CVE-2021-22945", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22945", + "severity": "Medium" + }, + "CVE-2023-44444": { + "id": "CVE-2023-44444", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44444", + "severity": "High" + }, + "CVE-2022-40743": { + "id": "CVE-2022-40743", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40743", + "severity": "High" + }, + "CVE-2023-28617": { + "id": "CVE-2023-28617", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28617", + "severity": "Critical" + }, + "CVE-2023-33733": { + "id": "CVE-2023-33733", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33733", + "severity": "High" + }, + "CVE-2020-27764": { + "id": "CVE-2020-27764", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27764", + "severity": "Medium" + }, + "CVE-2023-39418": { + "id": "CVE-2023-39418", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39418", + "severity": "High" + }, + "CVE-2022-41717": { + "id": "CVE-2022-41717", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41717", + "severity": "Medium" + }, + "CVE-2023-24329": { + "id": "CVE-2023-24329", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24329", + "severity": "High" + }, + "CVE-2024-28085": { + "id": "CVE-2024-28085", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28085", + "severity": "Low" + }, + "CVE-2021-20269": { + "id": "CVE-2021-20269", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20269", + "severity": "Medium" + }, + "CVE-2021-42781": { + "id": "CVE-2021-42781", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42781", + "severity": "Medium" + }, + "CVE-2021-3631": { + "id": "CVE-2021-3631", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3631", + "severity": "Medium" + }, + "CVE-2020-28914": { + "id": "CVE-2020-28914", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28914", + "severity": "High" + }, + "CVE-2021-0146": { + "id": "CVE-2021-0146", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0146", + "severity": "High" + }, + "CVE-2021-36374": { + "id": "CVE-2021-36374", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36374", + "severity": "Medium" + }, + "CVE-2022-27664": { + "id": "CVE-2022-27664", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27664", + "severity": "High" + }, + "CVE-2021-3544": { + "id": "CVE-2021-3544", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3544", + "severity": "High" + }, + "CVE-2022-3775": { + "id": "CVE-2022-3775", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3775", + "severity": "Medium" + }, + "CVE-2023-0464": { + "id": "CVE-2023-0464", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0464", + "severity": "High" + }, + "CVE-2022-0436": { + "id": "CVE-2022-0436", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0436", + "severity": "Medium" + }, + "CVE-2023-26136": { + "id": "CVE-2023-26136", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26136", + "severity": "Critical" + }, + "CVE-2024-1597": { + "id": "CVE-2024-1597", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1597", + "severity": "Critical" + }, + "CVE-2022-47024": { + "id": "CVE-2022-47024", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47024", + "severity": "High" + }, + "CVE-2021-33516": { + "id": "CVE-2021-33516", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33516", + "severity": "High" + }, + "CVE-2023-5981": { + "id": "CVE-2023-5981", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5981", + "severity": "Medium" + }, + "CVE-2022-48624": { + "id": "CVE-2022-48624", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48624", + "severity": "Low" + }, + "CVE-2023-21967": { + "id": "CVE-2023-21967", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21967", + "severity": "Medium" + }, + "CVE-2023-22084": { + "id": "CVE-2023-22084", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22084", + "severity": "Medium" + }, + "CVE-2022-24070": { + "id": "CVE-2022-24070", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24070", + "severity": "Medium" + }, + "CVE-2022-42890": { + "id": "CVE-2022-42890", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42890", + "severity": "High" + }, + "CVE-2017-17446": { + "id": "CVE-2017-17446", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-17446", + "severity": "Medium" + }, + "CVE-2020-26298": { + "id": "CVE-2020-26298", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26298", + "severity": "Medium" + }, + "CVE-2022-40320": { + "id": "CVE-2022-40320", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40320", + "severity": "High" + }, + "CVE-2024-1298": { + "id": "CVE-2024-1298", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1298", + "severity": "Medium" + }, + "CVE-2022-42004": { + "id": "CVE-2022-42004", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42004", + "severity": "High" + }, + "CVE-2024-27305": { + "id": "CVE-2024-27305", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27305", + "severity": "Medium" + }, + "CVE-2023-23946": { + "id": "CVE-2023-23946", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23946", + "severity": "Medium" + }, + "CVE-2023-33204": { + "id": "CVE-2023-33204", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33204", + "severity": "High" + }, + "CVE-2022-21624": { + "id": "CVE-2022-21624", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21624", + "severity": "Low" + }, + "CVE-2023-39742": { + "id": "CVE-2023-39742", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39742", + "severity": "Medium" + }, + "CVE-2021-21704": { + "id": "CVE-2021-21704", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21704", + "severity": "Medium" + }, + "CVE-2022-3643": { + "id": "CVE-2022-3643", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3643", + "severity": "Critical" + }, + "CVE-2020-15999": { + "id": "CVE-2020-15999", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15999", + "severity": "High" + }, + "CVE-2022-28356": { + "id": "CVE-2022-28356", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28356", + "severity": "High" + }, + "CVE-2023-4921": { + "id": "CVE-2023-4921", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4921", + "severity": "Medium" + }, + "CVE-2020-15049": { + "id": "CVE-2020-15049", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15049", + "severity": "High" + }, + "CVE-2022-3204": { + "id": "CVE-2022-3204", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3204", + "severity": "High" + }, + "CVE-2021-20229": { + "id": "CVE-2021-20229", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20229", + "severity": "Medium" + }, + "CVE-2022-37434": { + "id": "CVE-2022-37434", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37434", + "severity": "Critical" + }, + "CVE-2022-27223": { + "id": "CVE-2022-27223", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27223", + "severity": "Medium" + }, + "CVE-2023-2828": { + "id": "CVE-2023-2828", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2828", + "severity": "High" + }, + "CVE-2022-32221": { + "id": "CVE-2022-32221", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32221", + "severity": "Medium" + }, + "CVE-2023-24538": { + "id": "CVE-2023-24538", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24538", + "severity": "High" + }, + "CVE-2022-23634": { + "id": "CVE-2022-23634", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23634", + "severity": "Medium" + }, + "CVE-2022-2845": { + "id": "CVE-2022-2845", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2845", + "severity": "High" + }, + "CVE-2021-4209": { + "id": "CVE-2021-4209", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4209", + "severity": "Medium" + }, + "CVE-2023-2008": { + "id": "CVE-2023-2008", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2008", + "severity": "High" + }, + "CVE-2022-23037": { + "id": "CVE-2022-23037", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23037", + "severity": "Medium" + }, + "CVE-2023-6481": { + "id": "CVE-2023-6481", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6481", + "severity": "High" + }, + "CVE-2023-46316": { + "id": "CVE-2023-46316", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46316", + "severity": "Critical" + }, + "CVE-2022-39956": { + "id": "CVE-2022-39956", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39956", + "severity": "Critical" + }, + "CVE-2021-3565": { + "id": "CVE-2021-3565", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3565", + "severity": "Medium" + }, + "CVE-2021-39537": { + "id": "CVE-2021-39537", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39537", + "severity": "High" + }, + "CVE-2020-18442": { + "id": "CVE-2020-18442", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-18442", + "severity": "Medium" + }, + "CVE-2023-46045": { + "id": "CVE-2023-46045", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46045", + "severity": "Low" + }, + "CVE-2021-42097": { + "id": "CVE-2021-42097", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42097", + "severity": "Medium" + }, + "CVE-2023-1786": { + "id": "CVE-2023-1786", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1786", + "severity": "Medium" + }, + "CVE-2022-48303": { + "id": "CVE-2022-48303", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48303", + "severity": "High" + }, + "CVE-2021-4192": { + "id": "CVE-2021-4192", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4192", + "severity": "High" + }, + "CVE-2023-3446": { + "id": "CVE-2023-3446", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3446", + "severity": "Medium" + }, + "CVE-2023-30861": { + "id": "CVE-2023-30861", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30861", + "severity": "High" + }, + "CVE-2021-36090": { + "id": "CVE-2021-36090", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36090", + "severity": "High" + }, + "CVE-2020-27840": { + "id": "CVE-2020-27840", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27840", + "severity": "High" + }, + "CVE-2022-39188": { + "id": "CVE-2022-39188", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39188", + "severity": "Medium" + }, + "CVE-2021-40330": { + "id": "CVE-2021-40330", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40330", + "severity": "High" + }, + "CVE-2022-2255": { + "id": "CVE-2022-2255", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2255", + "severity": "Medium" + }, + "CVE-2020-11523": { + "id": "CVE-2020-11523", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11523", + "severity": "Medium" + }, + "CVE-2024-3177": { + "id": "CVE-2024-3177", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3177", + "severity": "Low" + }, + "CVE-2023-28642": { + "id": "CVE-2023-28642", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28642", + "severity": "Medium" + }, + "CVE-2019-0210": { + "id": "CVE-2019-0210", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0210", + "severity": "High" + }, + "CVE-2022-2586": { + "id": "CVE-2022-2586", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2586", + "severity": "High" + }, + "CVE-2021-20305": { + "id": "CVE-2021-20305", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20305", + "severity": "High" + }, + "CVE-2022-4065": { + "id": "CVE-2022-4065", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4065", + "severity": "High" + }, + "CVE-2021-31535": { + "id": "CVE-2021-31535", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31535", + "severity": "Critical" + }, + "CVE-2024-35943": { + "id": "CVE-2024-35943", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35943", + "severity": "Medium" + }, + "CVE-2022-25255": { + "id": "CVE-2022-25255", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25255", + "severity": "High" + }, + "CVE-2023-2985": { + "id": "CVE-2023-2985", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2985", + "severity": "Medium" + }, + "CVE-2022-3650": { + "id": "CVE-2022-3650", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3650", + "severity": "Low" + }, + "CVE-2022-4095": { + "id": "CVE-2022-4095", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4095", + "severity": "High" + }, + "CVE-2021-3782": { + "id": "CVE-2021-3782", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3782", + "severity": "Medium" + }, + "CVE-2022-43358": { + "id": "CVE-2022-43358", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43358", + "severity": "High" + }, + "CVE-2024-35221": { + "id": "CVE-2024-35221", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35221", + "severity": "Medium" + }, + "CVE-2023-0590": { + "id": "CVE-2023-0590", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0590", + "severity": "Medium" + }, + "CVE-2021-4156": { + "id": "CVE-2021-4156", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4156", + "severity": "High" + }, + "CVE-2023-2728": { + "id": "CVE-2023-2728", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2728", + "severity": "Medium" + }, + "CVE-2020-17380": { + "id": "CVE-2020-17380", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17380", + "severity": "Medium" + }, + "CVE-2022-33070": { + "id": "CVE-2022-33070", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33070", + "severity": "Medium" + }, + "CVE-2021-33503": { + "id": "CVE-2021-33503", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33503", + "severity": "High" + }, + "CVE-2024-26811": { + "id": "CVE-2024-26811", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26811", + "severity": "High" + }, + "CVE-2021-32028": { + "id": "CVE-2021-32028", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32028", + "severity": "Medium" + }, + "CVE-2021-46784": { + "id": "CVE-2021-46784", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46784", + "severity": "High" + }, + "CVE-2022-2639": { + "id": "CVE-2022-2639", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2639", + "severity": "High" + }, + "CVE-2023-34967": { + "id": "CVE-2023-34967", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34967", + "severity": "Medium" + }, + "CVE-2022-21949": { + "id": "CVE-2022-21949", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21949", + "severity": "High" + }, + "CVE-2022-3213": { + "id": "CVE-2022-3213", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3213", + "severity": "Medium" + }, + "CVE-2023-47212": { + "id": "CVE-2023-47212", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47212", + "severity": "High" + }, + "CVE-2024-2961": { + "id": "CVE-2024-2961", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2961", + "severity": "High" + }, + "CVE-2021-38185": { + "id": "CVE-2021-38185", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38185", + "severity": "High" + }, + "CVE-2021-27923": { + "id": "CVE-2021-27923", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27923", + "severity": "Medium" + }, + "CVE-2021-47477": { + "id": "CVE-2021-47477", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47477", + "severity": "Medium" + }, + "CVE-2013-4235": { + "id": "CVE-2013-4235", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4235", + "severity": "Medium" + }, + "CVE-2021-3781": { + "id": "CVE-2021-3781", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3781", + "severity": "Critical" + }, + "CVE-2021-23343": { + "id": "CVE-2021-23343", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23343", + "severity": "High" + }, + "CVE-2020-25721": { + "id": "CVE-2020-25721", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25721", + "severity": "Medium" + }, + "CVE-2021-28650": { + "id": "CVE-2021-28650", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28650", + "severity": "Medium" + }, + "CVE-2023-32763": { + "id": "CVE-2023-32763", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32763", + "severity": "High" + }, + "CVE-2022-2509": { + "id": "CVE-2022-2509", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2509", + "severity": "High" + }, + "CVE-2020-17437": { + "id": "CVE-2020-17437", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17437", + "severity": "High" + }, + "CVE-2022-40674": { + "id": "CVE-2022-40674", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40674", + "severity": "Critical" + }, + "CVE-2020-8031": { + "id": "CVE-2020-8031", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8031", + "severity": "Medium" + }, + "CVE-2023-46049": { + "id": "CVE-2023-46049", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46049", + "severity": "Low" + }, + "CVE-2021-38604": { + "id": "CVE-2021-38604", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38604", + "severity": "High" + }, + "CVE-2023-36191": { + "id": "CVE-2023-36191", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36191", + "severity": "Medium" + }, + "CVE-2023-43665": { + "id": "CVE-2023-43665", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43665", + "severity": "Medium" + }, + "CVE-2021-30641": { + "id": "CVE-2021-30641", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30641", + "severity": "Medium" + }, + "CVE-2021-20298": { + "id": "CVE-2021-20298", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20298", + "severity": "High" + }, + "CVE-2023-32681": { + "id": "CVE-2023-32681", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32681", + "severity": "Medium" + }, + "CVE-2019-17531": { + "id": "CVE-2019-17531", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17531", + "severity": "Critical" + }, + "CVE-2023-34153": { + "id": "CVE-2023-34153", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34153", + "severity": "Medium" + }, + "CVE-2023-40890": { + "id": "CVE-2023-40890", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40890", + "severity": "Critical" + }, + "CVE-2023-20197": { + "id": "CVE-2023-20197", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20197", + "severity": "High" + }, + "CVE-2021-41819": { + "id": "CVE-2021-41819", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41819", + "severity": "High" + }, + "CVE-2016-1000104": { + "id": "CVE-2016-1000104", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-1000104", + "severity": "High" + }, + "CVE-2024-24786": { + "id": "CVE-2024-24786", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24786", + "severity": "High" + }, + "CVE-2024-26641": { + "id": "CVE-2024-26641", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26641", + "severity": "Low" + }, + "CVE-2021-23177": { + "id": "CVE-2021-23177", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23177", + "severity": "Medium" + }, + "CVE-2021-44964": { + "id": "CVE-2021-44964", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44964", + "severity": "Medium" + }, + "CVE-2021-33656": { + "id": "CVE-2021-33656", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33656", + "severity": "Medium" + }, + "CVE-2021-2441": { + "id": "CVE-2021-2441", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2441", + "severity": "Medium" + }, + "CVE-2022-22815": { + "id": "CVE-2022-22815", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22815", + "severity": "Critical" + }, + "CVE-2022-2906": { + "id": "CVE-2022-2906", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2906", + "severity": "High" + }, + "CVE-2019-13173": { + "id": "CVE-2019-13173", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13173", + "severity": "High" + }, + "CVE-2022-0561": { + "id": "CVE-2022-0561", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0561", + "severity": "Medium" + }, + "CVE-2023-48795": { + "id": "CVE-2023-48795", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48795", + "severity": "Medium" + }, + "CVE-2022-27455": { + "id": "CVE-2022-27455", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27455", + "severity": "High" + }, + "CVE-2021-23980": { + "id": "CVE-2021-23980", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23980", + "severity": "Medium" + }, + "CVE-2010-3996": { + "id": "CVE-2010-3996", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-3996", + "severity": "High" + }, + "CVE-2023-4039": { + "id": "CVE-2023-4039", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4039", + "severity": "Medium" + }, + "CVE-2022-32743": { + "id": "CVE-2022-32743", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32743", + "severity": "Medium" + }, + "CVE-2023-49994": { + "id": "CVE-2023-49994", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49994", + "severity": "Medium" + }, + "CVE-2021-26690": { + "id": "CVE-2021-26690", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26690", + "severity": "High" + }, + "CVE-2022-23471": { + "id": "CVE-2022-23471", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23471", + "severity": "Medium" + }, + "CVE-2021-4048": { + "id": "CVE-2021-4048", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4048", + "severity": "Medium" + }, + "CVE-2022-29170": { + "id": "CVE-2022-29170", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29170", + "severity": "High" + }, + "CVE-2023-42755": { + "id": "CVE-2023-42755", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42755", + "severity": "Medium" + }, + "CVE-2023-1281": { + "id": "CVE-2023-1281", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1281", + "severity": "Medium" + }, + "CVE-2022-31107": { + "id": "CVE-2022-31107", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31107", + "severity": "High" + }, + "CVE-2021-29464": { + "id": "CVE-2021-29464", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29464", + "severity": "Medium" + }, + "CVE-2019-19308": { + "id": "CVE-2019-19308", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19308", + "severity": "Medium" + }, + "CVE-2023-35887": { + "id": "CVE-2023-35887", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35887", + "severity": "Medium" + }, + "CVE-2022-4744": { + "id": "CVE-2022-4744", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4744", + "severity": "Medium" + }, + "CVE-2022-22824": { + "id": "CVE-2022-22824", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22824", + "severity": "Critical" + }, + "CVE-2019-20379": { + "id": "CVE-2019-20379", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20379", + "severity": "Medium" + }, + "CVE-2019-11040": { + "id": "CVE-2019-11040", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11040", + "severity": "High" + }, + "CVE-2020-14410": { + "id": "CVE-2020-14410", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14410", + "severity": "High" + }, + "CVE-2021-46848": { + "id": "CVE-2021-46848", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46848", + "severity": "Critical" + }, + "CVE-2023-40551": { + "id": "CVE-2023-40551", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40551", + "severity": "High" + }, + "CVE-2023-25690": { + "id": "CVE-2023-25690", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25690", + "severity": "Medium" + }, + "CVE-2018-1313": { + "id": "CVE-2018-1313", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1313", + "severity": "Medium" + }, + "CVE-2023-31484": { + "id": "CVE-2023-31484", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31484", + "severity": "High" + }, + "CVE-2023-45803": { + "id": "CVE-2023-45803", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45803", + "severity": "Medium" + }, + "CVE-2024-26898": { + "id": "CVE-2024-26898", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26898", + "severity": "Medium" + }, + "CVE-2023-29007": { + "id": "CVE-2023-29007", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29007", + "severity": "High" + }, + "CVE-2021-37136": { + "id": "CVE-2021-37136", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37136", + "severity": "High" + }, + "CVE-2019-12295": { + "id": "CVE-2019-12295", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12295", + "severity": "High" + }, + "CVE-2020-27779": { + "id": "CVE-2020-27779", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27779", + "severity": "High" + }, + "CVE-2021-41098": { + "id": "CVE-2021-41098", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41098", + "severity": "High" + }, + "CVE-2023-22794": { + "id": "CVE-2023-22794", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22794", + "severity": "High" + }, + "CVE-2024-24814": { + "id": "CVE-2024-24814", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24814", + "severity": "High" + }, + "CVE-2023-31047": { + "id": "CVE-2023-31047", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31047", + "severity": "Critical" + }, + "CVE-2022-0699": { + "id": "CVE-2022-0699", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0699", + "severity": "Medium" + }, + "CVE-2023-52622": { + "id": "CVE-2023-52622", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52622", + "severity": "Medium" + }, + "CVE-2019-3881": { + "id": "CVE-2019-3881", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3881", + "severity": "High" + }, + "CVE-2023-5678": { + "id": "CVE-2023-5678", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5678", + "severity": "Medium" + }, + "CVE-2022-39176": { + "id": "CVE-2022-39176", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39176", + "severity": "Medium" + }, + "CVE-2021-43521": { + "id": "CVE-2021-43521", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43521", + "severity": "High" + }, + "CVE-2021-20299": { + "id": "CVE-2021-20299", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20299", + "severity": "High" + }, + "CVE-2023-7008": { + "id": "CVE-2023-7008", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7008", + "severity": "Medium" + }, + "CVE-2021-41617": { + "id": "CVE-2021-41617", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41617", + "severity": "High" + }, + "CVE-2020-6851": { + "id": "CVE-2020-6851", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6851", + "severity": "High" + }, + "CVE-2021-33629": { + "id": "CVE-2021-33629", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33629", + "severity": "Low" + }, + "CVE-2024-32462": { + "id": "CVE-2024-32462", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32462", + "severity": "High" + }, + "CVE-2023-37328": { + "id": "CVE-2023-37328", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37328", + "severity": "Medium" + }, + "CVE-2021-28165": { + "id": "CVE-2021-28165", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28165", + "severity": "High" + }, + "CVE-2024-21087": { + "id": "CVE-2024-21087", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21087", + "severity": "Medium" + }, + "CVE-2022-21540": { + "id": "CVE-2022-21540", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21540", + "severity": "High" + }, + "CVE-2022-40898": { + "id": "CVE-2022-40898", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40898", + "severity": "High" + }, + "CVE-2018-16438": { + "id": "CVE-2018-16438", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16438", + "severity": "High" + }, + "CVE-2021-46829": { + "id": "CVE-2021-46829", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46829", + "severity": "High" + }, + "CVE-2021-22930": { + "id": "CVE-2021-22930", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22930", + "severity": "High" + }, + "CVE-2022-3577": { + "id": "CVE-2022-3577", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3577", + "severity": "Medium" + }, + "CVE-2022-1354": { + "id": "CVE-2022-1354", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1354", + "severity": "Medium" + }, + "CVE-2016-9841": { + "id": "CVE-2016-9841", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9841", + "severity": "Critical" + }, + "CVE-2022-24806": { + "id": "CVE-2022-24806", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24806", + "severity": "Medium" + }, + "CVE-2020-16117": { + "id": "CVE-2020-16117", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16117", + "severity": "Medium" + }, + "CVE-2020-24372": { + "id": "CVE-2020-24372", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24372", + "severity": "High" + }, + "CVE-2021-36740": { + "id": "CVE-2021-36740", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36740", + "severity": "Medium" + }, + "CVE-2023-0416": { + "id": "CVE-2023-0416", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0416", + "severity": "High" + }, + "CVE-2022-41859": { + "id": "CVE-2022-41859", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41859", + "severity": "High" + }, + "CVE-2022-1962": { + "id": "CVE-2022-1962", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1962", + "severity": "Medium" + }, + "CVE-2023-25577": { + "id": "CVE-2023-25577", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25577", + "severity": "Low" + }, + "CVE-2021-3520": { + "id": "CVE-2021-3520", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3520", + "severity": "Critical" + }, + "CVE-2022-34481": { + "id": "CVE-2022-34481", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34481", + "severity": "High" + }, + "CVE-2021-21347": { + "id": "CVE-2021-21347", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21347", + "severity": "Critical" + }, + "CVE-2023-2004": { + "id": "CVE-2023-2004", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2004", + "severity": "Medium" + }, + "CVE-2021-27803": { + "id": "CVE-2021-27803", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27803", + "severity": "High" + }, + "CVE-2022-21673": { + "id": "CVE-2022-21673", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21673", + "severity": "Medium" + }, + "CVE-2020-24512": { + "id": "CVE-2020-24512", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24512", + "severity": "Medium" + }, + "CVE-2022-41953": { + "id": "CVE-2022-41953", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41953", + "severity": "High" + }, + "CVE-2023-5217": { + "id": "CVE-2023-5217", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5217", + "severity": "High" + }, + "CVE-2021-38114": { + "id": "CVE-2021-38114", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38114", + "severity": "Medium" + }, + "CVE-2018-25032": { + "id": "CVE-2018-25032", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25032", + "severity": "High" + }, + "CVE-2021-2007": { + "id": "CVE-2021-2007", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2007", + "severity": "Medium" + }, + "CVE-2022-36765": { + "id": "CVE-2022-36765", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36765", + "severity": "High" + }, + "CVE-2023-24540": { + "id": "CVE-2023-24540", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24540", + "severity": "High" + }, + "CVE-2022-23303": { + "id": "CVE-2022-23303", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23303", + "severity": "Critical" + }, + "CVE-2023-4863": { + "id": "CVE-2023-4863", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4863", + "severity": "High" + }, + "CVE-2023-39368": { + "id": "CVE-2023-39368", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39368", + "severity": "Medium" + }, + "CVE-2022-47630": { + "id": "CVE-2022-47630", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47630", + "severity": "High" + }, + "CVE-2024-4418": { + "id": "CVE-2024-4418", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4418", + "severity": "Medium" + }, + "CVE-2021-32563": { + "id": "CVE-2021-32563", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32563", + "severity": "Critical" + }, + "CVE-2022-21618": { + "id": "CVE-2022-21618", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21618", + "severity": "Medium" + }, + "CVE-2022-24407": { + "id": "CVE-2022-24407", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24407", + "severity": "Critical" + }, + "CVE-2023-25330": { + "id": "CVE-2023-25330", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25330", + "severity": "Critical" + }, + "CVE-2023-3428": { + "id": "CVE-2023-3428", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3428", + "severity": "Medium" + }, + "CVE-2022-21426": { + "id": "CVE-2022-21426", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21426", + "severity": "Medium" + }, + "CVE-2022-31163": { + "id": "CVE-2022-31163", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31163", + "severity": "High" + }, + "CVE-2023-30362": { + "id": "CVE-2023-30362", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30362", + "severity": "High" + }, + "CVE-2020-25651": { + "id": "CVE-2020-25651", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25651", + "severity": "Medium" + }, + "CVE-2021-43860": { + "id": "CVE-2021-43860", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43860", + "severity": "High" + }, + "CVE-2022-23773": { + "id": "CVE-2022-23773", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23773", + "severity": "High" + }, + "CVE-2022-28893": { + "id": "CVE-2022-28893", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28893", + "severity": "High" + }, + "CVE-2021-25122": { + "id": "CVE-2021-25122", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25122", + "severity": "High" + }, + "CVE-2019-15892": { + "id": "CVE-2019-15892", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15892", + "severity": "High" + }, + "CVE-2021-3596": { + "id": "CVE-2021-3596", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3596", + "severity": "Medium" + }, + "CVE-2021-3670": { + "id": "CVE-2021-3670", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3670", + "severity": "Medium" + }, + "CVE-2021-41092": { + "id": "CVE-2021-41092", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41092", + "severity": "Medium" + }, + "CVE-2022-0213": { + "id": "CVE-2022-0213", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0213", + "severity": "High" + }, + "CVE-2023-31122": { + "id": "CVE-2023-31122", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31122", + "severity": "Critical" + }, + "CVE-2023-25567": { + "id": "CVE-2023-25567", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25567", + "severity": "Medium" + }, + "CVE-2024-22365": { + "id": "CVE-2024-22365", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22365", + "severity": "Medium" + }, + "CVE-2022-37026": { + "id": "CVE-2022-37026", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37026", + "severity": "Critical" + }, + "CVE-2023-23931": { + "id": "CVE-2023-23931", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23931", + "severity": "Medium" + }, + "CVE-2023-39804": { + "id": "CVE-2023-39804", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39804", + "severity": "Low" + }, + "CVE-2021-28211": { + "id": "CVE-2021-28211", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28211", + "severity": "Medium" + }, + "CVE-2022-2995": { + "id": "CVE-2022-2995", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2995", + "severity": "High" + }, + "CVE-2021-47229": { + "id": "CVE-2021-47229", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47229", + "severity": "Medium" + }, + "CVE-2023-4056": { + "id": "CVE-2023-4056", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4056", + "severity": "High" + }, + "CVE-2023-52604": { + "id": "CVE-2023-52604", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52604", + "severity": "High" + }, + "CVE-2021-3672": { + "id": "CVE-2021-3672", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3672", + "severity": "Medium" + }, + "CVE-2024-3652": { + "id": "CVE-2024-3652", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3652", + "severity": "Low" + }, + "CVE-2020-36430": { + "id": "CVE-2020-36430", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36430", + "severity": "High" + }, + "CVE-2023-43804": { + "id": "CVE-2023-43804", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43804", + "severity": "Medium" + }, + "CVE-2023-28840": { + "id": "CVE-2023-28840", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28840", + "severity": "Medium" + }, + "CVE-2019-12521": { + "id": "CVE-2019-12521", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12521", + "severity": "Medium" + }, + "CVE-2021-3905": { + "id": "CVE-2021-3905", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3905", + "severity": "High" + }, + "CVE-2022-22827": { + "id": "CVE-2022-22827", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22827", + "severity": "High" + }, + "CVE-2021-42260": { + "id": "CVE-2021-42260", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42260", + "severity": "High" + }, + "CVE-2024-38607": { + "id": "CVE-2024-38607", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38607", + "severity": "Medium" + }, + "CVE-2021-47355": { + "id": "CVE-2021-47355", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47355", + "severity": "Medium" + }, + "CVE-2020-36386": { + "id": "CVE-2020-36386", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36386", + "severity": "Medium" + }, + "CVE-2023-40225": { + "id": "CVE-2023-40225", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40225", + "severity": "High" + }, + "CVE-2023-43040": { + "id": "CVE-2023-43040", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43040", + "severity": "Low" + }, + "CVE-2022-45199": { + "id": "CVE-2022-45199", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45199", + "severity": "High" + }, + "CVE-2019-13574": { + "id": "CVE-2019-13574", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13574", + "severity": "High" + }, + "CVE-2023-0465": { + "id": "CVE-2023-0465", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0465", + "severity": "High" + }, + "CVE-2021-36086": { + "id": "CVE-2021-36086", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36086", + "severity": "Low" + }, + "CVE-2022-1705": { + "id": "CVE-2022-1705", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1705", + "severity": "Medium" + }, + "CVE-2022-28330": { + "id": "CVE-2022-28330", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28330", + "severity": "Medium" + }, + "CVE-2022-23181": { + "id": "CVE-2022-23181", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23181", + "severity": "High" + }, + "CVE-2024-38636": { + "id": "CVE-2024-38636", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38636", + "severity": "High" + }, + "CVE-2022-2309": { + "id": "CVE-2022-2309", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2309", + "severity": "High" + }, + "CVE-2024-3447": { + "id": "CVE-2024-3447", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3447", + "severity": "Medium" + }, + "CVE-2021-3570": { + "id": "CVE-2021-3570", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3570", + "severity": "High" + }, + "CVE-2020-10001": { + "id": "CVE-2020-10001", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10001", + "severity": "Medium" + }, + "CVE-2020-28491": { + "id": "CVE-2020-28491", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28491", + "severity": "High" + }, + "CVE-2019-12519": { + "id": "CVE-2019-12519", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12519", + "severity": "Critical" + }, + "CVE-2023-0615": { + "id": "CVE-2023-0615", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0615", + "severity": "Medium" + }, + "CVE-2019-17195": { + "id": "CVE-2019-17195", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17195", + "severity": "Critical" + }, + "CVE-2024-25082": { + "id": "CVE-2024-25082", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25082", + "severity": "Medium" + }, + "CVE-2022-21713": { + "id": "CVE-2022-21713", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21713", + "severity": "High" + }, + "CVE-2023-39193": { + "id": "CVE-2023-39193", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39193", + "severity": "Medium" + }, + "CVE-2021-46823": { + "id": "CVE-2021-46823", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46823", + "severity": "Medium" + }, + "CVE-2020-0198": { + "id": "CVE-2020-0198", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0198", + "severity": "High" + }, + "CVE-2024-0209": { + "id": "CVE-2024-0209", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0209", + "severity": "High" + }, + "CVE-2022-24963": { + "id": "CVE-2022-24963", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24963", + "severity": "Critical" + }, + "CVE-2023-1175": { + "id": "CVE-2023-1175", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1175", + "severity": "High" + }, + "CVE-2023-5632": { + "id": "CVE-2023-5632", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5632", + "severity": "High" + }, + "CVE-2021-43082": { + "id": "CVE-2021-43082", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43082", + "severity": "High" + }, + "CVE-2021-47547": { + "id": "CVE-2021-47547", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47547", + "severity": "Medium" + }, + "CVE-2022-34917": { + "id": "CVE-2022-34917", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34917", + "severity": "High" + }, + "CVE-2023-0466": { + "id": "CVE-2023-0466", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0466", + "severity": "High" + }, + "CVE-2022-40899": { + "id": "CVE-2022-40899", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40899", + "severity": "High" + }, + "CVE-2021-3839": { + "id": "CVE-2021-3839", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3839", + "severity": "Medium" + }, + "CVE-2020-35653": { + "id": "CVE-2020-35653", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35653", + "severity": "High" + }, + "CVE-2024-5742": { + "id": "CVE-2024-5742", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5742", + "severity": "Medium" + }, + "CVE-2021-33633": { + "id": "CVE-2021-33633", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33633", + "severity": "High" + }, + "CVE-2021-3588": { + "id": "CVE-2021-3588", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3588", + "severity": "Low" + }, + "CVE-2022-42898": { + "id": "CVE-2022-42898", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42898", + "severity": "Medium" + }, + "CVE-2023-6531": { + "id": "CVE-2023-6531", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6531", + "severity": "High" + }, + "CVE-2022-26981": { + "id": "CVE-2022-26981", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26981", + "severity": "High" + }, + "CVE-2022-47011": { + "id": "CVE-2022-47011", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47011", + "severity": "High" + }, + "CVE-2022-0934": { + "id": "CVE-2022-0934", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0934", + "severity": "Medium" + }, + "CVE-2021-41973": { + "id": "CVE-2021-41973", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41973", + "severity": "Medium" + }, + "CVE-2024-26696": { + "id": "CVE-2024-26696", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26696", + "severity": "High" + }, + "CVE-2022-42916": { + "id": "CVE-2022-42916", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42916", + "severity": "High" + }, + "CVE-2021-43396": { + "id": "CVE-2021-43396", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43396", + "severity": "High" + }, + "CVE-2022-48174": { + "id": "CVE-2022-48174", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48174", + "severity": "Critical" + }, + "CVE-2023-52795": { + "id": "CVE-2023-52795", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52795", + "severity": "Medium" + }, + "CVE-2024-20696": { + "id": "CVE-2024-20696", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20696", + "severity": "High" + }, + "CVE-2019-18389": { + "id": "CVE-2019-18389", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18389", + "severity": "High" + }, + "CVE-2021-3595": { + "id": "CVE-2021-3595", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3595", + "severity": "Low" + }, + "CVE-2020-36773": { + "id": "CVE-2020-36773", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36773", + "severity": "Critical" + }, + "CVE-2020-15166": { + "id": "CVE-2020-15166", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15166", + "severity": "High" + }, + "CVE-2020-8908": { + "id": "CVE-2020-8908", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8908", + "severity": "Low" + }, + "CVE-2020-12321": { + "id": "CVE-2020-12321", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12321", + "severity": "High" + }, + "CVE-2022-48340": { + "id": "CVE-2022-48340", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48340", + "severity": "High" + }, + "CVE-2022-3560": { + "id": "CVE-2022-3560", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3560", + "severity": "Medium" + }, + "CVE-2022-29804": { + "id": "CVE-2022-29804", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29804", + "severity": "Medium" + }, + "CVE-2024-24897": { + "id": "CVE-2024-24897", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24897", + "severity": "High" + }, + "CVE-2023-39978": { + "id": "CVE-2023-39978", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39978", + "severity": "High" + }, + "CVE-2024-27282": { + "id": "CVE-2024-27282", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27282", + "severity": "Low" + }, + "CVE-2021-39251": { + "id": "CVE-2021-39251", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39251", + "severity": "High" + }, + "CVE-2023-35824": { + "id": "CVE-2023-35824", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35824", + "severity": "High" + }, + "CVE-2021-43975": { + "id": "CVE-2021-43975", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43975", + "severity": "High" + }, + "CVE-2022-21499": { + "id": "CVE-2022-21499", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21499", + "severity": "High" + }, + "CVE-2022-25168": { + "id": "CVE-2022-25168", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25168", + "severity": "Critical" + }, + "CVE-2021-22876": { + "id": "CVE-2021-22876", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22876", + "severity": "Low" + }, + "CVE-2020-26143": { + "id": "CVE-2020-26143", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26143", + "severity": "Medium" + }, + "CVE-2023-44487": { + "id": "CVE-2023-44487", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44487", + "severity": "High" + }, + "CVE-2015-20107": { + "id": "CVE-2015-20107", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-20107", + "severity": "Critical" + }, + "CVE-2022-42328": { + "id": "CVE-2022-42328", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42328", + "severity": "High" + }, + "CVE-2024-29156": { + "id": "CVE-2024-29156", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29156", + "severity": "High" + }, + "CVE-2024-28757": { + "id": "CVE-2024-28757", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28757", + "severity": "Medium" + }, + "CVE-2022-36087": { + "id": "CVE-2022-36087", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36087", + "severity": "Medium" + }, + "CVE-2022-1652": { + "id": "CVE-2022-1652", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1652", + "severity": "Medium" + }, + "CVE-2024-38662": { + "id": "CVE-2024-38662", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38662", + "severity": "Medium" + }, + "CVE-2023-1801": { + "id": "CVE-2023-1801", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1801", + "severity": "Medium" + }, + "CVE-2022-3172": { + "id": "CVE-2022-3172", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3172", + "severity": "Medium" + }, + "CVE-2021-3177": { + "id": "CVE-2021-3177", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3177", + "severity": "Critical" + }, + "CVE-2020-11864": { + "id": "CVE-2020-11864", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11864", + "severity": "Medium" + }, + "CVE-2020-14394": { + "id": "CVE-2020-14394", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14394", + "severity": "Low" + }, + "CVE-2023-3389": { + "id": "CVE-2023-3389", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3389", + "severity": "High" + }, + "CVE-2021-25215": { + "id": "CVE-2021-25215", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25215", + "severity": "Medium" + }, + "CVE-2019-7548": { + "id": "CVE-2019-7548", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7548", + "severity": "Medium" + }, + "CVE-2024-38553": { + "id": "CVE-2024-38553", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38553", + "severity": "High" + }, + "CVE-2023-42669": { + "id": "CVE-2023-42669", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42669", + "severity": "Medium" + }, + "CVE-2023-34410": { + "id": "CVE-2023-34410", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34410", + "severity": "Medium" + }, + "CVE-2021-28169": { + "id": "CVE-2021-28169", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28169", + "severity": "Medium" + }, + "CVE-2023-45664": { + "id": "CVE-2023-45664", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45664", + "severity": "High" + }, + "CVE-2022-0891": { + "id": "CVE-2022-0891", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0891", + "severity": "Medium" + }, + "CVE-2021-28831": { + "id": "CVE-2021-28831", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28831", + "severity": "High" + }, + "CVE-2023-35829": { + "id": "CVE-2023-35829", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35829", + "severity": "High" + }, + "CVE-2024-28882": { + "id": "CVE-2024-28882", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28882", + "severity": "Medium" + }, + "CVE-2021-39275": { + "id": "CVE-2021-39275", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39275", + "severity": "High" + }, + "CVE-2020-10719": { + "id": "CVE-2020-10719", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10719", + "severity": "Medium" + }, + "CVE-2014-0158": { + "id": "CVE-2014-0158", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-0158", + "severity": "High" + }, + "CVE-2020-27769": { + "id": "CVE-2020-27769", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27769", + "severity": "High" + }, + "CVE-2021-20190": { + "id": "CVE-2021-20190", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20190", + "severity": "High" + }, + "CVE-2023-28756": { + "id": "CVE-2023-28756", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28756", + "severity": "Medium" + }, + "CVE-2021-3623": { + "id": "CVE-2021-3623", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3623", + "severity": "Medium" + }, + "CVE-2022-31030": { + "id": "CVE-2022-31030", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31030", + "severity": "Medium" + }, + "CVE-2021-47538": { + "id": "CVE-2021-47538", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47538", + "severity": "Medium" + }, + "CVE-2023-52890": { + "id": "CVE-2023-52890", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52890", + "severity": "Medium" + }, + "CVE-2022-46285": { + "id": "CVE-2022-46285", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46285", + "severity": "High" + }, + "CVE-2023-34241": { + "id": "CVE-2023-34241", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34241", + "severity": "Medium" + }, + "CVE-2021-20227": { + "id": "CVE-2021-20227", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20227", + "severity": "Medium" + }, + "CVE-2024-39331": { + "id": "CVE-2024-39331", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39331", + "severity": "High" + }, + "CVE-2022-44638": { + "id": "CVE-2022-44638", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44638", + "severity": "High" + }, + "CVE-2023-6121": { + "id": "CVE-2023-6121", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6121", + "severity": "High" + }, + "CVE-2024-34459": { + "id": "CVE-2024-34459", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34459", + "severity": "Low" + }, + "CVE-2023-22115": { + "id": "CVE-2023-22115", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22115", + "severity": "Medium" + }, + "CVE-2020-36242": { + "id": "CVE-2020-36242", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36242", + "severity": "Critical" + }, + "CVE-2021-4069": { + "id": "CVE-2021-4069", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4069", + "severity": "High" + }, + "CVE-2020-16121": { + "id": "CVE-2020-16121", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16121", + "severity": "Low" + }, + "CVE-2021-46312": { + "id": "CVE-2021-46312", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46312", + "severity": "Medium" + }, + "CVE-2021-26937": { + "id": "CVE-2021-26937", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26937", + "severity": "Critical" + }, + "CVE-2022-1270": { + "id": "CVE-2022-1270", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1270", + "severity": "High" + }, + "CVE-2020-1753": { + "id": "CVE-2020-1753", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1753", + "severity": "Low" + }, + "CVE-2023-43114": { + "id": "CVE-2023-43114", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43114", + "severity": "High" + }, + "CVE-2021-26291": { + "id": "CVE-2021-26291", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26291", + "severity": "Critical" + }, + "CVE-2021-42782": { + "id": "CVE-2021-42782", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42782", + "severity": "Medium" + }, + "CVE-2021-32292": { + "id": "CVE-2021-32292", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32292", + "severity": "Critical" + }, + "CVE-2016-10198": { + "id": "CVE-2016-10198", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10198", + "severity": "Medium" + }, + "CVE-2021-40346": { + "id": "CVE-2021-40346", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40346", + "severity": "High" + }, + "CVE-2023-51698": { + "id": "CVE-2023-51698", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51698", + "severity": "High" + }, + "CVE-2021-4083": { + "id": "CVE-2021-4083", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4083", + "severity": "High" + }, + "CVE-2021-3903": { + "id": "CVE-2021-3903", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3903", + "severity": "High" + }, + "CVE-2024-32487": { + "id": "CVE-2024-32487", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32487", + "severity": "Medium" + }, + "CVE-2019-10174": { + "id": "CVE-2019-10174", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10174", + "severity": "High" + }, + "CVE-2020-29260": { + "id": "CVE-2020-29260", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29260", + "severity": "High" + }, + "CVE-2024-36387": { + "id": "CVE-2024-36387", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36387", + "severity": "Low" + }, + "CVE-2023-1017": { + "id": "CVE-2023-1017", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1017", + "severity": "Medium" + }, + "CVE-2024-39470": { + "id": "CVE-2024-39470", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39470", + "severity": "Medium" + }, + "CVE-2020-36185": { + "id": "CVE-2020-36185", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36185", + "severity": "High" + }, + "CVE-2021-3521": { + "id": "CVE-2021-3521", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3521", + "severity": "Low" + }, + "CVE-2021-4122": { + "id": "CVE-2021-4122", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4122", + "severity": "Medium" + }, + "CVE-2021-20223": { + "id": "CVE-2021-20223", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20223", + "severity": "Critical" + }, + "CVE-2021-25317": { + "id": "CVE-2021-25317", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25317", + "severity": "Low" + }, + "CVE-2014-9640": { + "id": "CVE-2014-9640", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-9640", + "severity": "Medium" + }, + "CVE-2021-43400": { + "id": "CVE-2021-43400", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43400", + "severity": "Critical" + }, + "CVE-2021-21703": { + "id": "CVE-2021-21703", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21703", + "severity": "High" + }, + "CVE-2023-4132": { + "id": "CVE-2023-4132", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4132", + "severity": "Medium" + }, + "CVE-2024-1151": { + "id": "CVE-2024-1151", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1151", + "severity": "Medium" + }, + "CVE-2022-4304": { + "id": "CVE-2022-4304", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4304", + "severity": "Medium" + }, + "CVE-2023-45235": { + "id": "CVE-2023-45235", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45235", + "severity": "High" + }, + "CVE-2006-20001": { + "id": "CVE-2006-20001", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2006-20001", + "severity": "Critical" + }, + "CVE-2024-36946": { + "id": "CVE-2024-36946", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36946", + "severity": "None" + }, + "CVE-2022-2320": { + "id": "CVE-2022-2320", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2320", + "severity": "High" + }, + "CVE-2022-23645": { + "id": "CVE-2022-23645", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23645", + "severity": "Medium" + }, + "CVE-2022-2068": { + "id": "CVE-2022-2068", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2068", + "severity": "Critical" + }, + "CVE-2021-33574": { + "id": "CVE-2021-33574", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33574", + "severity": "Critical" + }, + "CVE-2020-8625": { + "id": "CVE-2020-8625", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8625", + "severity": "High" + }, + "CVE-2020-25097": { + "id": "CVE-2020-25097", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25097", + "severity": "High" + }, + "CVE-2023-28204": { + "id": "CVE-2023-28204", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28204", + "severity": "Medium" + }, + "CVE-2023-3618": { + "id": "CVE-2023-3618", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3618", + "severity": "Medium" + }, + "CVE-2020-8277": { + "id": "CVE-2020-8277", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8277", + "severity": "High" + }, + "CVE-2023-2283": { + "id": "CVE-2023-2283", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2283", + "severity": "Medium" + }, + "CVE-2021-39242": { + "id": "CVE-2021-39242", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39242", + "severity": "High" + }, + "CVE-2022-28738": { + "id": "CVE-2022-28738", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28738", + "severity": "Medium" + }, + "CVE-2020-36241": { + "id": "CVE-2020-36241", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36241", + "severity": "Medium" + }, + "CVE-2022-41715": { + "id": "CVE-2022-41715", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41715", + "severity": "Medium" + }, + "CVE-2020-7598": { + "id": "CVE-2020-7598", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7598", + "severity": "Medium" + }, + "CVE-2020-1971": { + "id": "CVE-2020-1971", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1971", + "severity": "Medium" + }, + "CVE-2022-27337": { + "id": "CVE-2022-27337", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27337", + "severity": "Medium" + }, + "CVE-2020-28896": { + "id": "CVE-2020-28896", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28896", + "severity": "Medium" + }, + "CVE-2021-4217": { + "id": "CVE-2021-4217", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4217", + "severity": "Medium" + }, + "CVE-2021-47208": { + "id": "CVE-2021-47208", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47208", + "severity": "High" + }, + "CVE-2023-28321": { + "id": "CVE-2023-28321", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28321", + "severity": "Medium" + }, + "CVE-2023-24998": { + "id": "CVE-2023-24998", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24998", + "severity": "High" + }, + "CVE-2021-3872": { + "id": "CVE-2021-3872", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3872", + "severity": "Medium" + }, + "CVE-2022-1771": { + "id": "CVE-2022-1771", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1771", + "severity": "High" + }, + "CVE-2022-40284": { + "id": "CVE-2022-40284", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40284", + "severity": "High" + }, + "CVE-2023-29532": { + "id": "CVE-2023-29532", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29532", + "severity": "High" + }, + "CVE-2023-2513": { + "id": "CVE-2023-2513", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2513", + "severity": "High" + }, + "CVE-2020-15890": { + "id": "CVE-2020-15890", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15890", + "severity": "High" + }, + "CVE-2020-27845": { + "id": "CVE-2020-27845", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27845", + "severity": "High" + }, + "CVE-2021-2042": { + "id": "CVE-2021-2042", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2042", + "severity": "Medium" + }, + "CVE-2022-31629": { + "id": "CVE-2022-31629", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31629", + "severity": "Medium" + }, + "CVE-2021-43818": { + "id": "CVE-2021-43818", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43818", + "severity": "High" + }, + "CVE-2023-45539": { + "id": "CVE-2023-45539", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45539", + "severity": "High" + }, + "CVE-2020-25710": { + "id": "CVE-2020-25710", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25710", + "severity": "High" + }, + "CVE-2019-10219": { + "id": "CVE-2019-10219", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10219", + "severity": "Medium" + }, + "CVE-2020-13959": { + "id": "CVE-2020-13959", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13959", + "severity": "Medium" + }, + "CVE-2020-18032": { + "id": "CVE-2020-18032", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-18032", + "severity": "Critical" + }, + "CVE-2021-23222": { + "id": "CVE-2021-23222", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23222", + "severity": "High" + }, + "CVE-2020-35538": { + "id": "CVE-2020-35538", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35538", + "severity": "Medium" + }, + "CVE-2024-24806": { + "id": "CVE-2024-24806", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24806", + "severity": "Critical" + }, + "CVE-2024-35235": { + "id": "CVE-2024-35235", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35235", + "severity": "Medium" + }, + "CVE-2023-52138": { + "id": "CVE-2023-52138", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52138", + "severity": "Critical" + }, + "CVE-2021-43809": { + "id": "CVE-2021-43809", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43809", + "severity": "High" + }, + "CVE-2021-28210": { + "id": "CVE-2021-28210", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28210", + "severity": "High" + }, + "CVE-2024-26144": { + "id": "CVE-2024-26144", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26144", + "severity": "Medium" + }, + "CVE-2023-33933": { + "id": "CVE-2023-33933", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33933", + "severity": "High" + }, + "CVE-2019-25058": { + "id": "CVE-2019-25058", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25058", + "severity": "High" + }, + "CVE-2023-49286": { + "id": "CVE-2023-49286", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49286", + "severity": "High" + }, + "CVE-2023-5535": { + "id": "CVE-2023-5535", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5535", + "severity": "High" + }, + "CVE-2021-47210": { + "id": "CVE-2021-47210", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47210", + "severity": "Medium" + }, + "CVE-2019-7164": { + "id": "CVE-2019-7164", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7164", + "severity": "Critical" + }, + "CVE-2021-38115": { + "id": "CVE-2021-38115", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38115", + "severity": "Medium" + }, + "CVE-2022-47939": { + "id": "CVE-2022-47939", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47939", + "severity": "Medium" + }, + "CVE-2022-42919": { + "id": "CVE-2022-42919", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42919", + "severity": "High" + }, + "CVE-2022-2153": { + "id": "CVE-2022-2153", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2153", + "severity": "Low" + }, + "CVE-2020-28935": { + "id": "CVE-2020-28935", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28935", + "severity": "Medium" + }, + "CVE-2024-27351": { + "id": "CVE-2024-27351", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27351", + "severity": "High" + }, + "CVE-2022-0924": { + "id": "CVE-2022-0924", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0924", + "severity": "Medium" + }, + "CVE-2024-31083": { + "id": "CVE-2024-31083", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31083", + "severity": "High" + }, + "CVE-2020-27783": { + "id": "CVE-2020-27783", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27783", + "severity": "Medium" + }, + "CVE-2021-21300": { + "id": "CVE-2021-21300", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21300", + "severity": "High" + }, + "CVE-2022-28391": { + "id": "CVE-2022-28391", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28391", + "severity": "Critical" + }, + "CVE-2022-41678": { + "id": "CVE-2022-41678", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41678", + "severity": "High" + }, + "CVE-2020-21679": { + "id": "CVE-2020-21679", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-21679", + "severity": "Medium" + }, + "CVE-2022-41850": { + "id": "CVE-2022-41850", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41850", + "severity": "High" + }, + "CVE-2022-41881": { + "id": "CVE-2022-41881", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41881", + "severity": "High" + }, + "CVE-2021-47549": { + "id": "CVE-2021-47549", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47549", + "severity": "Medium" + }, + "CVE-2023-46728": { + "id": "CVE-2023-46728", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46728", + "severity": "High" + }, + "CVE-2023-39128": { + "id": "CVE-2023-39128", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39128", + "severity": "Medium" + }, + "CVE-2021-23383": { + "id": "CVE-2021-23383", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23383", + "severity": "Critical" + }, + "CVE-2021-39360": { + "id": "CVE-2021-39360", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39360", + "severity": "Medium" + }, + "CVE-2020-24240": { + "id": "CVE-2020-24240", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24240", + "severity": "Medium" + }, + "CVE-2023-6228": { + "id": "CVE-2023-6228", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6228", + "severity": "Low" + }, + "CVE-2020-15673": { + "id": "CVE-2020-15673", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15673", + "severity": "High" + }, + "CVE-2022-45062": { + "id": "CVE-2022-45062", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45062", + "severity": "Critical" + }, + "CVE-2022-27781": { + "id": "CVE-2022-27781", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27781", + "severity": "Medium" + }, + "CVE-2022-23302": { + "id": "CVE-2022-23302", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23302", + "severity": "High" + }, + "CVE-2020-28463": { + "id": "CVE-2020-28463", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28463", + "severity": "Medium" + }, + "CVE-2023-2977": { + "id": "CVE-2023-2977", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2977", + "severity": "High" + }, + "CVE-2024-37388": { + "id": "CVE-2024-37388", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37388", + "severity": "Medium" + }, + "CVE-2021-35938": { + "id": "CVE-2021-35938", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35938", + "severity": "Medium" + }, + "CVE-2021-20232": { + "id": "CVE-2021-20232", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20232", + "severity": "Critical" + }, + "CVE-2021-43813": { + "id": "CVE-2021-43813", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43813", + "severity": "Medium" + }, + "CVE-2021-42523": { + "id": "CVE-2021-42523", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42523", + "severity": "High" + }, + "CVE-2023-3354": { + "id": "CVE-2023-3354", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3354", + "severity": "High" + }, + "CVE-2023-46604": { + "id": "CVE-2023-46604", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46604", + "severity": "Critical" + }, + "CVE-2021-29338": { + "id": "CVE-2021-29338", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29338", + "severity": "Medium" + }, + "CVE-2022-45939": { + "id": "CVE-2022-45939", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45939", + "severity": "High" + }, + "CVE-2024-34062": { + "id": "CVE-2024-34062", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34062", + "severity": "Medium" + }, + "CVE-2016-0750": { + "id": "CVE-2016-0750", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-0750", + "severity": "High" + }, + "CVE-2023-26545": { + "id": "CVE-2023-26545", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26545", + "severity": "High" + }, + "CVE-2021-3713": { + "id": "CVE-2021-3713", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3713", + "severity": "High" + }, + "CVE-2022-1328": { + "id": "CVE-2022-1328", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1328", + "severity": "Medium" + }, + "CVE-2023-3817": { + "id": "CVE-2023-3817", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3817", + "severity": "Medium" + }, + "CVE-2024-21068": { + "id": "CVE-2024-21068", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21068", + "severity": "High" + }, + "CVE-2019-14744": { + "id": "CVE-2019-14744", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14744", + "severity": "High" + }, + "CVE-2023-2157": { + "id": "CVE-2023-2157", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2157", + "severity": "Medium" + }, + "CVE-2022-41853": { + "id": "CVE-2022-41853", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41853", + "severity": "Critical" + }, + "CVE-2016-3709": { + "id": "CVE-2016-3709", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3709", + "severity": "Medium" + }, + "CVE-2021-3997": { + "id": "CVE-2021-3997", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3997", + "severity": "Medium" + }, + "CVE-2023-23009": { + "id": "CVE-2023-23009", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23009", + "severity": "High" + }, + "CVE-2021-45078": { + "id": "CVE-2021-45078", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45078", + "severity": "High" + }, + "CVE-2022-48682": { + "id": "CVE-2022-48682", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48682", + "severity": "Medium" + }, + "CVE-2024-0641": { + "id": "CVE-2024-0641", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0641", + "severity": "Medium" + }, + "CVE-2023-3812": { + "id": "CVE-2023-3812", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3812", + "severity": "High" + }, + "CVE-2023-4641": { + "id": "CVE-2023-4641", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4641", + "severity": "Low" + }, + "CVE-2022-25235": { + "id": "CVE-2022-25235", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25235", + "severity": "High" + }, + "CVE-2021-45985": { + "id": "CVE-2021-45985", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45985", + "severity": "High" + }, + "CVE-2021-41229": { + "id": "CVE-2021-41229", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41229", + "severity": "Medium" + }, + "CVE-2019-13508": { + "id": "CVE-2019-13508", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13508", + "severity": "Critical" + }, + "CVE-2022-26354": { + "id": "CVE-2022-26354", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26354", + "severity": "High" + }, + "CVE-2022-47021": { + "id": "CVE-2022-47021", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47021", + "severity": "High" + }, + "CVE-2020-21428": { + "id": "CVE-2020-21428", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-21428", + "severity": "High" + }, + "CVE-2019-25051": { + "id": "CVE-2019-25051", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25051", + "severity": "High" + }, + "CVE-2023-2976": { + "id": "CVE-2023-2976", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2976", + "severity": "High" + }, + "CVE-2021-3541": { + "id": "CVE-2021-3541", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3541", + "severity": "Medium" + }, + "CVE-2021-4011": { + "id": "CVE-2021-4011", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4011", + "severity": "High" + }, + "CVE-2022-25315": { + "id": "CVE-2022-25315", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25315", + "severity": "Critical" + }, + "CVE-2024-1062": { + "id": "CVE-2024-1062", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1062", + "severity": "Medium" + }, + "CVE-2024-0409": { + "id": "CVE-2024-0409", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0409", + "severity": "High" + }, + "CVE-2022-37454": { + "id": "CVE-2022-37454", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37454", + "severity": "Critical" + }, + "CVE-2022-24130": { + "id": "CVE-2022-24130", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24130", + "severity": "Medium" + }, + "CVE-2020-12762": { + "id": "CVE-2020-12762", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12762", + "severity": "High" + }, + "CVE-2023-29383": { + "id": "CVE-2023-29383", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29383", + "severity": "Low" + }, + "CVE-2023-5841": { + "id": "CVE-2023-5841", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5841", + "severity": "Critical" + }, + "CVE-2022-26691": { + "id": "CVE-2022-26691", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26691", + "severity": "Medium" + }, + "CVE-2024-38477": { + "id": "CVE-2024-38477", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38477", + "severity": "High" + }, + "CVE-2022-44789": { + "id": "CVE-2022-44789", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44789", + "severity": "High" + }, + "CVE-2022-29187": { + "id": "CVE-2022-29187", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29187", + "severity": "High" + }, + "CVE-2021-28429": { + "id": "CVE-2021-28429", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28429", + "severity": "Medium" + }, + "CVE-2022-43551": { + "id": "CVE-2022-43551", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43551", + "severity": "Medium" + }, + "CVE-2023-1994": { + "id": "CVE-2023-1994", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1994", + "severity": "Medium" + }, + "CVE-2023-49797": { + "id": "CVE-2023-49797", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49797", + "severity": "High" + }, + "CVE-2020-36323": { + "id": "CVE-2020-36323", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36323", + "severity": "High" + }, + "CVE-2021-44142": { + "id": "CVE-2021-44142", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44142", + "severity": "Critical" + }, + "CVE-2023-1668": { + "id": "CVE-2023-1668", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1668", + "severity": "High" + }, + "CVE-2023-0266": { + "id": "CVE-2023-0266", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0266", + "severity": "High" + }, + "CVE-2021-20288": { + "id": "CVE-2021-20288", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20288", + "severity": "High" + }, + "CVE-2021-37533": { + "id": "CVE-2021-37533", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37533", + "severity": "Medium" + }, + "CVE-2024-5700": { + "id": "CVE-2024-5700", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5700", + "severity": "Low" + }, + "CVE-2021-43045": { + "id": "CVE-2021-43045", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43045", + "severity": "High" + }, + "CVE-2021-3984": { + "id": "CVE-2021-3984", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3984", + "severity": "High" + }, + "CVE-2021-25740": { + "id": "CVE-2021-25740", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25740", + "severity": "Low" + }, + "CVE-2020-13936": { + "id": "CVE-2020-13936", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13936", + "severity": "High" + }, + "CVE-2021-3634": { + "id": "CVE-2021-3634", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3634", + "severity": "Medium" + }, + "CVE-2021-33515": { + "id": "CVE-2021-33515", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33515", + "severity": "Medium" + }, + "CVE-2022-3099": { + "id": "CVE-2022-3099", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3099", + "severity": "High" + }, + "CVE-2023-37732": { + "id": "CVE-2023-37732", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37732", + "severity": "Medium" + }, + "CVE-2021-3472": { + "id": "CVE-2021-3472", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3472", + "severity": "High" + }, + "CVE-2021-23807": { + "id": "CVE-2021-23807", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23807", + "severity": "Critical" + }, + "CVE-2022-23833": { + "id": "CVE-2022-23833", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23833", + "severity": "High" + }, + "CVE-2021-44879": { + "id": "CVE-2021-44879", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44879", + "severity": "Medium" + }, + "CVE-2024-30205": { + "id": "CVE-2024-30205", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30205", + "severity": "Medium" + }, + "CVE-2023-45918": { + "id": "CVE-2023-45918", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45918", + "severity": "Low" + }, + "CVE-2023-0809": { + "id": "CVE-2023-0809", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0809", + "severity": "Medium" + }, + "CVE-2020-14145": { + "id": "CVE-2020-14145", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14145", + "severity": "Medium" + }, + "CVE-2021-3575": { + "id": "CVE-2021-3575", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3575", + "severity": "Medium" + }, + "CVE-2024-35176": { + "id": "CVE-2024-35176", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35176", + "severity": "Medium" + }, + "CVE-2021-3677": { + "id": "CVE-2021-3677", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3677", + "severity": "Medium" + }, + "CVE-2023-38428": { + "id": "CVE-2023-38428", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38428", + "severity": "High" + }, + "CVE-2023-4781": { + "id": "CVE-2023-4781", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4781", + "severity": "High" + }, + "CVE-2022-47952": { + "id": "CVE-2022-47952", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47952", + "severity": "Low" + }, + "CVE-2022-48468": { + "id": "CVE-2022-48468", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48468", + "severity": "Critical" + }, + "CVE-2023-4759": { + "id": "CVE-2023-4759", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4759", + "severity": "High" + }, + "CVE-2023-29406": { + "id": "CVE-2023-29406", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29406", + "severity": "Critical" + }, + "CVE-2019-18934": { + "id": "CVE-2019-18934", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18934", + "severity": "Medium" + }, + "CVE-2023-52449": { + "id": "CVE-2023-52449", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52449", + "severity": "High" + }, + "CVE-2020-25211": { + "id": "CVE-2020-25211", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25211", + "severity": "Medium" + }, + "CVE-2024-31047": { + "id": "CVE-2024-31047", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31047", + "severity": "Medium" + }, + "CVE-2023-43898": { + "id": "CVE-2023-43898", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43898", + "severity": "Medium" + }, + "CVE-2022-40982": { + "id": "CVE-2022-40982", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40982", + "severity": "Medium" + }, + "CVE-2023-45871": { + "id": "CVE-2023-45871", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45871", + "severity": "Medium" + }, + "CVE-2022-22844": { + "id": "CVE-2022-22844", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22844", + "severity": "Medium" + }, + "CVE-2023-52742": { + "id": "CVE-2023-52742", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52742", + "severity": "Medium" + }, + "CVE-2024-29018": { + "id": "CVE-2024-29018", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29018", + "severity": "Medium" + }, + "CVE-2016-9606": { + "id": "CVE-2016-9606", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9606", + "severity": "High" + }, + "CVE-2020-21913": { + "id": "CVE-2020-21913", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-21913", + "severity": "Medium" + }, + "CVE-2023-39197": { + "id": "CVE-2023-39197", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39197", + "severity": "Low" + }, + "CVE-2021-29468": { + "id": "CVE-2021-29468", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29468", + "severity": "High" + }, + "CVE-2022-29536": { + "id": "CVE-2022-29536", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29536", + "severity": "Medium" + }, + "CVE-2023-49284": { + "id": "CVE-2023-49284", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49284", + "severity": "Medium" + }, + "CVE-2022-3341": { + "id": "CVE-2022-3341", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3341", + "severity": "Medium" + }, + "CVE-2022-21434": { + "id": "CVE-2022-21434", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21434", + "severity": "Low" + }, + "CVE-2022-45198": { + "id": "CVE-2022-45198", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45198", + "severity": "High" + }, + "CVE-2019-11459": { + "id": "CVE-2019-11459", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11459", + "severity": "Medium" + }, + "CVE-2021-27906": { + "id": "CVE-2021-27906", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27906", + "severity": "Medium" + }, + "CVE-2016-3981": { + "id": "CVE-2016-3981", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3981", + "severity": "High" + }, + "CVE-2021-2341": { + "id": "CVE-2021-2341", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2341", + "severity": "High" + }, + "CVE-2024-2511": { + "id": "CVE-2024-2511", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2511", + "severity": "Medium" + }, + "CVE-2023-46219": { + "id": "CVE-2023-46219", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46219", + "severity": "Low" + }, + "CVE-2021-2357": { + "id": "CVE-2021-2357", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2357", + "severity": "Low" + }, + "CVE-2019-15026": { + "id": "CVE-2019-15026", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15026", + "severity": "High" + }, + "CVE-2024-26752": { + "id": "CVE-2024-26752", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26752", + "severity": "High" + }, + "CVE-2023-24593": { + "id": "CVE-2023-24593", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24593", + "severity": "Medium" + }, + "CVE-2022-24765": { + "id": "CVE-2022-24765", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24765", + "severity": "High" + }, + "CVE-2021-21309": { + "id": "CVE-2021-21309", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21309", + "severity": "Critical" + }, + "CVE-2021-44141": { + "id": "CVE-2021-44141", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44141", + "severity": "Medium" + }, + "CVE-2023-4911": { + "id": "CVE-2023-4911", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4911", + "severity": "High" + }, + "CVE-2020-28282": { + "id": "CVE-2020-28282", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28282", + "severity": "Critical" + }, + "CVE-2021-4034": { + "id": "CVE-2021-4034", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4034", + "severity": "High" + }, + "CVE-2022-36114": { + "id": "CVE-2022-36114", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36114", + "severity": "High" + }, + "CVE-2021-35942": { + "id": "CVE-2021-35942", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35942", + "severity": "Medium" + }, + "CVE-2021-47234": { + "id": "CVE-2021-47234", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47234", + "severity": "Low" + }, + "CVE-2021-28116": { + "id": "CVE-2021-28116", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28116", + "severity": "Medium" + }, + "CVE-2021-41133": { + "id": "CVE-2021-41133", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41133", + "severity": "High" + }, + "CVE-2022-24048": { + "id": "CVE-2022-24048", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24048", + "severity": "Medium" + }, + "CVE-2023-50269": { + "id": "CVE-2023-50269", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50269", + "severity": "High" + }, + "CVE-2023-26607": { + "id": "CVE-2023-26607", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26607", + "severity": "High" + }, + "CVE-2022-23308": { + "id": "CVE-2022-23308", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23308", + "severity": "High" + }, + "CVE-2023-22799": { + "id": "CVE-2023-22799", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22799", + "severity": "Medium" + }, + "CVE-2021-36222": { + "id": "CVE-2021-36222", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36222", + "severity": "High" + }, + "CVE-2022-22719": { + "id": "CVE-2022-22719", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22719", + "severity": "High" + }, + "CVE-2020-14352": { + "id": "CVE-2020-14352", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14352", + "severity": "High" + }, + "CVE-2022-3821": { + "id": "CVE-2022-3821", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3821", + "severity": "Medium" + }, + "CVE-2021-47154": { + "id": "CVE-2021-47154", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47154", + "severity": "Medium" + }, + "CVE-2022-1049": { + "id": "CVE-2022-1049", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1049", + "severity": "High" + }, + "CVE-2023-27534": { + "id": "CVE-2023-27534", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27534", + "severity": "Medium" + }, + "CVE-2020-35512": { + "id": "CVE-2020-35512", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35512", + "severity": "High" + }, + "CVE-2021-3996": { + "id": "CVE-2021-3996", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3996", + "severity": "Medium" + }, + "CVE-2023-6516": { + "id": "CVE-2023-6516", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6516", + "severity": "High" + }, + "CVE-2023-6176": { + "id": "CVE-2023-6176", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6176", + "severity": "Low" + }, + "CVE-2024-34083": { + "id": "CVE-2024-34083", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34083", + "severity": "Medium" + }, + "CVE-2021-3927": { + "id": "CVE-2021-3927", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3927", + "severity": "High" + }, + "CVE-2024-24789": { + "id": "CVE-2024-24789", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24789", + "severity": "Medium" + }, + "CVE-2021-45942": { + "id": "CVE-2021-45942", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45942", + "severity": "Medium" + }, + "CVE-2020-29509": { + "id": "CVE-2020-29509", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29509", + "severity": "Medium" + }, + "CVE-2017-12613": { + "id": "CVE-2017-12613", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12613", + "severity": "High" + }, + "CVE-2023-38289": { + "id": "CVE-2023-38289", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38289", + "severity": "Low" + }, + "CVE-2022-0494": { + "id": "CVE-2022-0494", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0494", + "severity": "High" + }, + "CVE-2022-41723": { + "id": "CVE-2022-41723", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41723", + "severity": "High" + }, + "CVE-2022-20141": { + "id": "CVE-2022-20141", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20141", + "severity": "High" + }, + "CVE-2022-0572": { + "id": "CVE-2022-0572", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0572", + "severity": "High" + }, + "CVE-2024-39467": { + "id": "CVE-2024-39467", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39467", + "severity": "Medium" + }, + "CVE-2021-20188": { + "id": "CVE-2021-20188", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20188", + "severity": "High" + }, + "CVE-2021-34141": { + "id": "CVE-2021-34141", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34141", + "severity": "High" + }, + "CVE-2023-45139": { + "id": "CVE-2023-45139", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45139", + "severity": "High" + }, + "CVE-2022-2097": { + "id": "CVE-2022-2097", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2097", + "severity": "High" + }, + "CVE-2021-22904": { + "id": "CVE-2021-22904", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22904", + "severity": "High" + }, + "CVE-2019-15961": { + "id": "CVE-2019-15961", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15961", + "severity": "Medium" + }, + "CVE-2024-3651": { + "id": "CVE-2024-3651", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3651", + "severity": "Medium" + }, + "CVE-2023-1095": { + "id": "CVE-2023-1095", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1095", + "severity": "Medium" + }, + "CVE-2023-38469": { + "id": "CVE-2023-38469", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38469", + "severity": "Medium" + }, + "CVE-2024-34402": { + "id": "CVE-2024-34402", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34402", + "severity": "Medium" + }, + "CVE-2022-25147": { + "id": "CVE-2022-25147", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25147", + "severity": "Critical" + }, + "CVE-2019-17626": { + "id": "CVE-2019-17626", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17626", + "severity": "Critical" + }, + "CVE-2024-27431": { + "id": "CVE-2024-27431", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27431", + "severity": "Medium" + }, + "CVE-2022-48554": { + "id": "CVE-2022-48554", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48554", + "severity": "Medium" + }, + "CVE-2021-3796": { + "id": "CVE-2021-3796", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3796", + "severity": "High" + }, + "CVE-2021-3981": { + "id": "CVE-2021-3981", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3981", + "severity": "Low" + }, + "CVE-2023-30608": { + "id": "CVE-2023-30608", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30608", + "severity": "High" + }, + "CVE-2024-39695": { + "id": "CVE-2024-39695", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39695", + "severity": "Medium" + }, + "CVE-2022-0943": { + "id": "CVE-2022-0943", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0943", + "severity": "High" + }, + "CVE-2023-4504": { + "id": "CVE-2023-4504", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4504", + "severity": "High" + }, + "CVE-2019-12067": { + "id": "CVE-2019-12067", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12067", + "severity": "Medium" + }, + "CVE-2020-15469": { + "id": "CVE-2020-15469", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15469", + "severity": "Low" + }, + "CVE-2021-35331": { + "id": "CVE-2021-35331", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35331", + "severity": "High" + }, + "CVE-2021-33638": { + "id": "CVE-2021-33638", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33638", + "severity": "Critical" + }, + "CVE-2022-29162": { + "id": "CVE-2022-29162", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29162", + "severity": "Medium" + }, + "CVE-2022-48064": { + "id": "CVE-2022-48064", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48064", + "severity": "Medium" + }, + "CVE-2021-20246": { + "id": "CVE-2021-20246", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20246", + "severity": "Low" + }, + "CVE-2023-21930": { + "id": "CVE-2023-21930", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21930", + "severity": "High" + }, + "CVE-2023-38559": { + "id": "CVE-2023-38559", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38559", + "severity": "Critical" + }, + "CVE-2022-1516": { + "id": "CVE-2022-1516", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1516", + "severity": "Medium" + }, + "CVE-2022-3134": { + "id": "CVE-2022-3134", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3134", + "severity": "High" + }, + "CVE-2024-32660": { + "id": "CVE-2024-32660", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32660", + "severity": "Critical" + }, + "CVE-2023-25136": { + "id": "CVE-2023-25136", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25136", + "severity": "Medium" + }, + "CVE-2022-45060": { + "id": "CVE-2022-45060", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45060", + "severity": "High" + }, + "CVE-2019-14900": { + "id": "CVE-2019-14900", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14900", + "severity": "Medium" + }, + "CVE-2022-2124": { + "id": "CVE-2022-2124", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2124", + "severity": "High" + }, + "CVE-2021-23336": { + "id": "CVE-2021-23336", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23336", + "severity": "High" + }, + "CVE-2021-38578": { + "id": "CVE-2021-38578", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38578", + "severity": "Critical" + }, + "CVE-2021-33036": { + "id": "CVE-2021-33036", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33036", + "severity": "High" + }, + "CVE-2023-51793": { + "id": "CVE-2023-51793", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51793", + "severity": "Critical" + }, + "CVE-2024-24892": { + "id": "CVE-2024-24892", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24892", + "severity": "High" + }, + "CVE-2023-40217": { + "id": "CVE-2023-40217", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40217", + "severity": "Medium" + }, + "CVE-2022-39260": { + "id": "CVE-2022-39260", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39260", + "severity": "Medium" + }, + "CVE-2022-42012": { + "id": "CVE-2022-42012", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42012", + "severity": "Medium" + }, + "CVE-2023-47100": { + "id": "CVE-2023-47100", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47100", + "severity": "Critical" + }, + "CVE-2019-11098": { + "id": "CVE-2019-11098", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11098", + "severity": "High" + }, + "CVE-2024-4467": { + "id": "CVE-2024-4467", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4467", + "severity": "High" + }, + "CVE-2024-5535": { + "id": "CVE-2024-5535", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5535", + "severity": "Medium" + }, + "CVE-2023-41080": { + "id": "CVE-2023-41080", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41080", + "severity": "Medium" + }, + "CVE-2022-41966": { + "id": "CVE-2022-41966", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41966", + "severity": "High" + }, + "CVE-2023-24056": { + "id": "CVE-2023-24056", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24056", + "severity": "Critical" + }, + "CVE-2023-4156": { + "id": "CVE-2023-4156", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4156", + "severity": "Low" + }, + "CVE-2020-28493": { + "id": "CVE-2020-28493", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28493", + "severity": "Medium" + }, + "CVE-2024-36971": { + "id": "CVE-2024-36971", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36971", + "severity": "Medium" + }, + "CVE-2024-6564": { + "id": "CVE-2024-6564", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6564", + "severity": "Medium" + }, + "CVE-2022-0175": { + "id": "CVE-2022-0175", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0175", + "severity": "Medium" + }, + "CVE-2023-1544": { + "id": "CVE-2023-1544", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1544", + "severity": "Medium" + }, + "CVE-2020-27842": { + "id": "CVE-2020-27842", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27842", + "severity": "Medium" + }, + "CVE-2021-24032": { + "id": "CVE-2021-24032", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24032", + "severity": "Critical" + }, + "CVE-2024-36039": { + "id": "CVE-2024-36039", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36039", + "severity": "High" + }, + "CVE-2023-4194": { + "id": "CVE-2023-4194", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4194", + "severity": "Medium" + }, + "CVE-2021-42717": { + "id": "CVE-2021-42717", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42717", + "severity": "High" + }, + "CVE-2022-2084": { + "id": "CVE-2022-2084", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2084", + "severity": "Medium" + }, + "CVE-2023-26130": { + "id": "CVE-2023-26130", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26130", + "severity": "High" + }, + "CVE-2021-38165": { + "id": "CVE-2021-38165", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38165", + "severity": "High" + }, + "CVE-2024-36006": { + "id": "CVE-2024-36006", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36006", + "severity": "Medium" + }, + "CVE-2023-0054": { + "id": "CVE-2023-0054", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0054", + "severity": "High" + }, + "CVE-2023-22999": { + "id": "CVE-2023-22999", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22999", + "severity": "High" + }, + "CVE-2023-23913": { + "id": "CVE-2023-23913", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23913", + "severity": "High" + }, + "CVE-2023-26555": { + "id": "CVE-2023-26555", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26555", + "severity": "Medium" + }, + "CVE-2016-9296": { + "id": "CVE-2016-9296", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9296", + "severity": "High" + }, + "CVE-2023-28938": { + "id": "CVE-2023-28938", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28938", + "severity": "Medium" + }, + "CVE-2019-17007": { + "id": "CVE-2019-17007", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17007", + "severity": "Medium" + }, + "CVE-2023-3576": { + "id": "CVE-2023-3576", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3576", + "severity": "Medium" + }, + "CVE-2018-16301": { + "id": "CVE-2018-16301", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16301", + "severity": "High" + }, + "CVE-2023-0666": { + "id": "CVE-2023-0666", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0666", + "severity": "Medium" + }, + "CVE-2020-10735": { + "id": "CVE-2020-10735", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10735", + "severity": "High" + }, + "CVE-2023-0047": { + "id": "CVE-2023-0047", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0047", + "severity": "High" + }, + "CVE-2022-45061": { + "id": "CVE-2022-45061", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45061", + "severity": "High" + }, + "CVE-2023-48706": { + "id": "CVE-2023-48706", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48706", + "severity": "Low" + }, + "CVE-2024-34397": { + "id": "CVE-2024-34397", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34397", + "severity": "Low" + }, + "CVE-2021-3571": { + "id": "CVE-2021-3571", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3571", + "severity": "High" + }, + "CVE-2022-30550": { + "id": "CVE-2022-30550", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30550", + "severity": "Medium" + }, + "CVE-2020-1695": { + "id": "CVE-2020-1695", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1695", + "severity": "High" + }, + "CVE-2022-30065": { + "id": "CVE-2022-30065", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30065", + "severity": "High" + }, + "CVE-2019-17185": { + "id": "CVE-2019-17185", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17185", + "severity": "Medium" + }, + "CVE-2020-14343": { + "id": "CVE-2020-14343", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14343", + "severity": "Critical" + }, + "CVE-2024-5458": { + "id": "CVE-2024-5458", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5458", + "severity": "Medium" + }, + "CVE-2023-0286": { + "id": "CVE-2023-0286", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0286", + "severity": "Medium" + }, + "CVE-2022-42329": { + "id": "CVE-2022-42329", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42329", + "severity": "Medium" + }, + "CVE-2020-15078": { + "id": "CVE-2020-15078", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15078", + "severity": "High" + }, + "CVE-2023-51798": { + "id": "CVE-2023-51798", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51798", + "severity": "Medium" + }, + "CVE-2024-33602": { + "id": "CVE-2024-33602", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33602", + "severity": "High" + }, + "CVE-2023-6277": { + "id": "CVE-2023-6277", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6277", + "severity": "Medium" + }, + "CVE-2021-41136": { + "id": "CVE-2021-41136", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41136", + "severity": "Low" + }, + "CVE-2021-43859": { + "id": "CVE-2021-43859", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43859", + "severity": "High" + }, + "CVE-2023-4459": { + "id": "CVE-2023-4459", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4459", + "severity": "Medium" + }, + "CVE-2023-40546": { + "id": "CVE-2023-40546", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40546", + "severity": "Medium" + }, + "CVE-2022-2031": { + "id": "CVE-2022-2031", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2031", + "severity": "Medium" + }, + "CVE-2020-12279": { + "id": "CVE-2020-12279", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12279", + "severity": "High" + }, + "CVE-2022-38150": { + "id": "CVE-2022-38150", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38150", + "severity": "High" + }, + "CVE-2021-41991": { + "id": "CVE-2021-41991", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41991", + "severity": "High" + }, + "CVE-2022-1802": { + "id": "CVE-2022-1802", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1802", + "severity": "High" + }, + "CVE-2021-22569": { + "id": "CVE-2021-22569", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22569", + "severity": "Medium" + }, + "CVE-2021-30145": { + "id": "CVE-2021-30145", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30145", + "severity": "High" + }, + "CVE-2020-6950": { + "id": "CVE-2020-6950", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6950", + "severity": "High" + }, + "CVE-2022-26280": { + "id": "CVE-2022-26280", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26280", + "severity": "Critical" + }, + "CVE-2022-1674": { + "id": "CVE-2022-1674", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1674", + "severity": "High" + }, + "CVE-2022-3705": { + "id": "CVE-2022-3705", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3705", + "severity": "High" + }, + "CVE-2023-23601": { + "id": "CVE-2023-23601", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23601", + "severity": "Medium" + }, + "CVE-2024-6383": { + "id": "CVE-2024-6383", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6383", + "severity": "Medium" + }, + "CVE-2018-17942": { + "id": "CVE-2018-17942", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17942", + "severity": "High" + }, + "CVE-2022-25310": { + "id": "CVE-2022-25310", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25310", + "severity": "High" + }, + "CVE-2021-45930": { + "id": "CVE-2021-45930", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45930", + "severity": "Medium" + }, + "CVE-2021-39358": { + "id": "CVE-2021-39358", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39358", + "severity": "Medium" + }, + "CVE-2023-28772": { + "id": "CVE-2023-28772", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28772", + "severity": "Medium" + }, + "CVE-2023-40476": { + "id": "CVE-2023-40476", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40476", + "severity": "High" + }, + "CVE-2024-28182": { + "id": "CVE-2024-28182", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28182", + "severity": "Medium" + }, + "CVE-2021-27135": { + "id": "CVE-2021-27135", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27135", + "severity": "Critical" + }, + "CVE-2020-28473": { + "id": "CVE-2020-28473", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28473", + "severity": "Medium" + }, + "CVE-2022-2869": { + "id": "CVE-2022-2869", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2869", + "severity": "High" + }, + "CVE-2021-3600": { + "id": "CVE-2021-3600", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3600", + "severity": "Medium" + }, + "CVE-2023-20052": { + "id": "CVE-2023-20052", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20052", + "severity": "Critical" + }, + "CVE-2024-23196": { + "id": "CVE-2024-23196", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23196", + "severity": "Medium" + }, + "CVE-2023-1264": { + "id": "CVE-2023-1264", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1264", + "severity": "Medium" + }, + "CVE-2023-42465": { + "id": "CVE-2023-42465", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42465", + "severity": "High" + }, + "CVE-2020-8265": { + "id": "CVE-2020-8265", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8265", + "severity": "Medium" + }, + "CVE-2021-29505": { + "id": "CVE-2021-29505", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29505", + "severity": "High" + }, + "CVE-2023-2650": { + "id": "CVE-2023-2650", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2650", + "severity": "High" + }, + "CVE-2017-6829": { + "id": "CVE-2017-6829", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6829", + "severity": "High" + }, + "CVE-2019-15144": { + "id": "CVE-2019-15144", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15144", + "severity": "High" + }, + "CVE-2024-1048": { + "id": "CVE-2024-1048", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1048", + "severity": "Low" + }, + "CVE-2023-39129": { + "id": "CVE-2023-39129", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39129", + "severity": "Medium" + }, + "CVE-2024-22211": { + "id": "CVE-2024-22211", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22211", + "severity": "Low" + }, + "CVE-2024-40971": { + "id": "CVE-2024-40971", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40971", + "severity": "High" + }, + "CVE-2023-41913": { + "id": "CVE-2023-41913", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41913", + "severity": "Critical" + }, + "CVE-2024-4741": { + "id": "CVE-2024-4741", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4741", + "severity": "Critical" + }, + "CVE-2024-20952": { + "id": "CVE-2024-20952", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20952", + "severity": "High" + }, + "CVE-2022-3028": { + "id": "CVE-2022-3028", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3028", + "severity": "High" + }, + "CVE-2023-41419": { + "id": "CVE-2023-41419", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41419", + "severity": "Critical" + }, + "CVE-2023-5380": { + "id": "CVE-2023-5380", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5380", + "severity": "High" + }, + "CVE-2021-27219": { + "id": "CVE-2021-27219", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27219", + "severity": "High" + }, + "CVE-2021-25743": { + "id": "CVE-2021-25743", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25743", + "severity": "Low" + }, + "CVE-2024-27074": { + "id": "CVE-2024-27074", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27074", + "severity": "Medium" + }, + "CVE-2021-3522": { + "id": "CVE-2021-3522", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3522", + "severity": "Medium" + }, + "CVE-2023-30630": { + "id": "CVE-2023-30630", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30630", + "severity": "Medium" + }, + "CVE-2021-28834": { + "id": "CVE-2021-28834", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28834", + "severity": "Critical" + }, + "CVE-2024-24785": { + "id": "CVE-2024-24785", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24785", + "severity": "High" + }, + "CVE-2020-12059": { + "id": "CVE-2020-12059", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12059", + "severity": "High" + }, + "CVE-2021-28168": { + "id": "CVE-2021-28168", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28168", + "severity": "Medium" + }, + "CVE-2021-21285": { + "id": "CVE-2021-21285", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21285", + "severity": "Medium" + }, + "CVE-2021-3753": { + "id": "CVE-2021-3753", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3753", + "severity": "Medium" + }, + "CVE-2023-6610": { + "id": "CVE-2023-6610", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6610", + "severity": "High" + }, + "CVE-2021-42376": { + "id": "CVE-2021-42376", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42376", + "severity": "High" + }, + "CVE-2023-3966": { + "id": "CVE-2023-3966", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3966", + "severity": "High" + }, + "CVE-2021-3618": { + "id": "CVE-2021-3618", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3618", + "severity": "High" + }, + "CVE-2024-32473": { + "id": "CVE-2024-32473", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32473", + "severity": "Medium" + }, + "CVE-2020-10759": { + "id": "CVE-2020-10759", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10759", + "severity": "Medium" + }, + "CVE-2023-23583": { + "id": "CVE-2023-23583", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23583", + "severity": "High" + }, + "CVE-2021-37750": { + "id": "CVE-2021-37750", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37750", + "severity": "Medium" + }, + "CVE-2022-1122": { + "id": "CVE-2022-1122", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1122", + "severity": "Medium" + }, + "CVE-2022-20572": { + "id": "CVE-2022-20572", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20572", + "severity": "High" + }, + "CVE-2021-43797": { + "id": "CVE-2021-43797", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43797", + "severity": "Medium" + }, + "CVE-2021-3429": { + "id": "CVE-2021-3429", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3429", + "severity": "Medium" + }, + "CVE-2023-50447": { + "id": "CVE-2023-50447", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50447", + "severity": "High" + }, + "CVE-2022-31197": { + "id": "CVE-2022-31197", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31197", + "severity": "High" + }, + "CVE-2020-15180": { + "id": "CVE-2020-15180", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15180", + "severity": "High" + }, + "CVE-2022-31779": { + "id": "CVE-2022-31779", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31779", + "severity": "High" + }, + "CVE-2021-29946": { + "id": "CVE-2021-29946", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29946", + "severity": "High" + }, + "CVE-2024-38540": { + "id": "CVE-2024-38540", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38540", + "severity": "Medium" + }, + "CVE-2013-0340": { + "id": "CVE-2013-0340", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-0340", + "severity": "Medium" + }, + "CVE-2022-0204": { + "id": "CVE-2022-0204", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0204", + "severity": "High" + }, + "CVE-2020-14339": { + "id": "CVE-2020-14339", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14339", + "severity": "High" + }, + "CVE-2024-5206": { + "id": "CVE-2024-5206", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5206", + "severity": "Medium" + }, + "CVE-2022-4662": { + "id": "CVE-2022-4662", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4662", + "severity": "Medium" + }, + "CVE-2022-22755": { + "id": "CVE-2022-22755", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22755", + "severity": "High" + }, + "CVE-2023-32700": { + "id": "CVE-2023-32700", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32700", + "severity": "High" + }, + "CVE-2022-20153": { + "id": "CVE-2022-20153", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20153", + "severity": "Medium" + }, + "CVE-2022-1292": { + "id": "CVE-2022-1292", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1292", + "severity": "Medium" + }, + "CVE-2021-36770": { + "id": "CVE-2021-36770", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36770", + "severity": "High" + }, + "CVE-2020-36229": { + "id": "CVE-2020-36229", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36229", + "severity": "High" + }, + "CVE-2022-1785": { + "id": "CVE-2022-1785", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1785", + "severity": "High" + }, + "CVE-2021-42574": { + "id": "CVE-2021-42574", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42574", + "severity": "High" + }, + "CVE-2020-28407": { + "id": "CVE-2020-28407", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28407", + "severity": "Medium" + }, + "CVE-2022-0336": { + "id": "CVE-2022-0336", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0336", + "severity": "High" + }, + "CVE-2020-26950": { + "id": "CVE-2020-26950", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26950", + "severity": "High" + }, + "CVE-2022-30594": { + "id": "CVE-2022-30594", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30594", + "severity": "Medium" + }, + "CVE-2022-3324": { + "id": "CVE-2022-3324", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3324", + "severity": "High" + }, + "CVE-2023-32559": { + "id": "CVE-2023-32559", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32559", + "severity": "High" + }, + "CVE-2023-37464": { + "id": "CVE-2023-37464", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37464", + "severity": "High" + }, + "CVE-2023-43789": { + "id": "CVE-2023-43789", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43789", + "severity": "Medium" + }, + "CVE-2024-26922": { + "id": "CVE-2024-26922", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26922", + "severity": "Medium" + }, + "CVE-2023-43115": { + "id": "CVE-2023-43115", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43115", + "severity": "Critical" + }, + "CVE-2019-8842": { + "id": "CVE-2019-8842", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8842", + "severity": "Low" + }, + "CVE-2022-27406": { + "id": "CVE-2022-27406", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27406", + "severity": "Critical" + }, + "CVE-2022-1616": { + "id": "CVE-2022-1616", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1616", + "severity": "Critical" + }, + "CVE-2021-3580": { + "id": "CVE-2021-3580", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3580", + "severity": "High" + }, + "CVE-2024-6409": { + "id": "CVE-2024-6409", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6409", + "severity": "High" + }, + "CVE-2016-9136": { + "id": "CVE-2016-9136", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9136", + "severity": "Medium" + }, + "CVE-2022-1552": { + "id": "CVE-2022-1552", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1552", + "severity": "High" + }, + "CVE-2023-0361": { + "id": "CVE-2023-0361", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0361", + "severity": "Medium" + }, + "CVE-2022-47016": { + "id": "CVE-2022-47016", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47016", + "severity": "High" + }, + "CVE-2023-33288": { + "id": "CVE-2023-33288", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33288", + "severity": "Medium" + }, + "CVE-2022-2000": { + "id": "CVE-2022-2000", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2000", + "severity": "High" + }, + "CVE-2021-37619": { + "id": "CVE-2021-37619", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37619", + "severity": "Medium" + }, + "CVE-2020-35738": { + "id": "CVE-2020-35738", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35738", + "severity": "Medium" + }, + "CVE-2022-39318": { + "id": "CVE-2022-39318", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39318", + "severity": "High" + }, + "CVE-2021-41183": { + "id": "CVE-2021-41183", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41183", + "severity": "Medium" + }, + "CVE-2023-52425": { + "id": "CVE-2023-52425", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52425", + "severity": "High" + }, + "CVE-2023-3255": { + "id": "CVE-2023-3255", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3255", + "severity": "Medium" + }, + "CVE-2023-0437": { + "id": "CVE-2023-0437", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0437", + "severity": "Medium" + }, + "CVE-2020-8284": { + "id": "CVE-2020-8284", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8284", + "severity": "High" + }, + "CVE-2023-22081": { + "id": "CVE-2023-22081", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22081", + "severity": "Medium" + }, + "CVE-2022-33099": { + "id": "CVE-2022-33099", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33099", + "severity": "High" + }, + "CVE-2023-25725": { + "id": "CVE-2023-25725", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25725", + "severity": "Medium" + }, + "CVE-2023-1108": { + "id": "CVE-2023-1108", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1108", + "severity": "High" + }, + "CVE-2021-40732": { + "id": "CVE-2021-40732", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40732", + "severity": "Medium" + }, + "CVE-2021-29425": { + "id": "CVE-2021-29425", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29425", + "severity": "Medium" + }, + "CVE-2023-1829": { + "id": "CVE-2023-1829", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1829", + "severity": "Medium" + }, + "CVE-2022-33967": { + "id": "CVE-2022-33967", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33967", + "severity": "Medium" + }, + "CVE-2022-20001": { + "id": "CVE-2022-20001", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20001", + "severity": "High" + }, + "CVE-2022-42252": { + "id": "CVE-2022-42252", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42252", + "severity": "High" + }, + "CVE-2019-16779": { + "id": "CVE-2019-16779", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16779", + "severity": "Medium" + }, + "CVE-2023-3592": { + "id": "CVE-2023-3592", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3592", + "severity": "High" + }, + "CVE-2021-33560": { + "id": "CVE-2021-33560", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33560", + "severity": "High" + }, + "CVE-2023-4128": { + "id": "CVE-2023-4128", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4128", + "severity": "Medium" + }, + "CVE-2022-4515": { + "id": "CVE-2022-4515", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4515", + "severity": "High" + }, + "CVE-2022-3924": { + "id": "CVE-2022-3924", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3924", + "severity": "High" + }, + "CVE-2023-2603": { + "id": "CVE-2023-2603", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2603", + "severity": "Low" + }, + "CVE-2021-27138": { + "id": "CVE-2021-27138", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27138", + "severity": "High" + }, + "CVE-2022-4450": { + "id": "CVE-2022-4450", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4450", + "severity": "High" + }, + "CVE-2019-13377": { + "id": "CVE-2019-13377", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13377", + "severity": "Medium" + }, + "CVE-2022-41318": { + "id": "CVE-2022-41318", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41318", + "severity": "Medium" + }, + "CVE-2015-8011": { + "id": "CVE-2015-8011", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8011", + "severity": "High" + }, + "CVE-2022-3628": { + "id": "CVE-2022-3628", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3628", + "severity": "Medium" + }, + "CVE-2021-29136": { + "id": "CVE-2021-29136", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29136", + "severity": "Medium" + }, + "CVE-2023-45667": { + "id": "CVE-2023-45667", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45667", + "severity": "Critical" + }, + "CVE-2020-13112": { + "id": "CVE-2020-13112", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13112", + "severity": "Critical" + }, + "CVE-2024-0567": { + "id": "CVE-2024-0567", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0567", + "severity": "Medium" + }, + "CVE-2022-32205": { + "id": "CVE-2022-32205", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32205", + "severity": "Medium" + }, + "CVE-2021-41039": { + "id": "CVE-2021-41039", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41039", + "severity": "High" + }, + "CVE-2021-38208": { + "id": "CVE-2021-38208", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38208", + "severity": "Medium" + }, + "CVE-2021-3712": { + "id": "CVE-2021-3712", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3712", + "severity": "High" + }, + "CVE-2023-50230": { + "id": "CVE-2023-50230", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50230", + "severity": "High" + }, + "CVE-2024-26601": { + "id": "CVE-2024-26601", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26601", + "severity": "Medium" + } +} \ No newline at end of file diff --git a/cvrf_sainfos.json b/cvrf_sainfos.json new file mode 100644 index 0000000..59faa00 --- /dev/null +++ b/cvrf_sainfos.json @@ -0,0 +1,42910 @@ +{ + "openEuler-SA-2022-2145": { + "id": "openEuler-SA-2022-2145", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-2145", + "title": "An update for openjdk-1.8.0 is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3 and openEuler-22.03-LTS", + "severity": "Medium", + "description": "The OpenJDK runtime environment 8.\r\n\r\n\r\n\r\nSecurity Fix(es):\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 7u321, 8u311, 11.0.13; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2022-21271)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JAXP). Supported versions that are affected are Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18; Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1 and 22.0.0.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2022-21426)", + "cves": [ + { + "id": "CVE-2022-21426", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21426", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1542": { + "id": "openEuler-SA-2023-1542", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1542", + "title": "An update for qpdf is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS,openEuler-22.03-LTS-SP1 and openEuler-22.03-LTS-SP2", + "severity": "High", + "description": "QPDF is a command-line program that does structural, content-preserving transformations on PDF files. It could have been called something like pdf-to-pdf. It also provides many useful capabilities to developers of PDF-producing software or for people who just want to look at the innards of a PDF file to learn more about how they work.\n\nSecurity Fix(es):\n\nAn issue was discovered in QPDF version 10.0.4, allows remote attackers to execute arbitrary code via crafted .pdf file to Pl_ASCII85Decoder::write parameter in libqpdf.(CVE-2021-25786)", + "cves": [ + { + "id": "CVE-2021-25786", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25786", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1703": { + "id": "openEuler-SA-2023-1703", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1703", + "title": "An update for cups is now available for openEuler-20.03-LTS-SP1", + "severity": "High", + "description": "CUPS is the standards-based, open source printing system developed by Apple Inc. for UNIX®-like operating systems. CUPS uses the Internet Printing Protocol (IPP) to support printing to local and network printers..\r\n\r\nSecurity Fix(es):\r\n\r\nDue to failure in validating the length provided by an attacker-crafted PPD PostScript document, CUPS and libppd are susceptible to a heap-based buffer overflow and possibly code execution. This issue has been fixed in CUPS version 2.4.7, released in September of 2023.\n(CVE-2023-4504)", + "cves": [ + { + "id": "CVE-2023-4504", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4504", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1738": { + "id": "openEuler-SA-2023-1738", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1738", + "title": "An update for openjdk-11 is now available for openEuler-20.03-LTS-SP3", + "severity": "High", + "description": "The OpenJDK runtime environment.\r\n\r\nSecurity Fix(es):\r\n\r\nAn issue was discovered in function ciMethodBlocks::make_block_at in Oracle JDK (HotSpot VM) 11, 17 and OpenJDK (HotSpot VM) 8, 11, 17, allows attackers to cause a denial of service.(CVE-2022-40433)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and 22.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via DTLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2023-21835)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Sound). Supported versions that are affected are Oracle Java SE: 8u351, 8u351-perf, 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and 22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21843)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).(CVE-2023-21930)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21937)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and 22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21938)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21939)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.9 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).(CVE-2023-21954)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H).(CVE-2023-21967)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21968)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).(CVE-2023-22006)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Utility). Supported versions that are affected are Oracle Java SE: 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2023-22036)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.1 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).(CVE-2023-22041)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2023-22045)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-22049)", + "cves": [ + { + "id": "CVE-2023-22049", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22049", + "severity": "High" + } + ] + }, + "openEuler-SA-2024-1465": { + "id": "openEuler-SA-2024-1465", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1465", + "title": "An update for docker is now available for openEuler-22.03-LTS", + "severity": "Medium", + "description": "Docker is an open source project to build, ship and run any application as a lightweight container.\r\n\r\nSecurity Fix(es):\r\n\r\nMoby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. Moby's networking implementation allows for many networks, each with their own IP address range and gateway, to be defined. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well.\r\n\r\nWhen containers with networking are created, they are assigned unique network interfaces and IP addresses. The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.\r\n\r\nContainers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.\r\n\r\nIn addition to configuring the Linux kernel's various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery, and resolution of names from an upstream resolver.\r\n\r\nWhen a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver. This request is made from the container's network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.\r\n\r\nAs a consequence of this design, containers solely attached to an internal network will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.\r\n\r\nMany systems run a local forwarding DNS resolver. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the host namework namespace. The loopback resolver then forwards the requests to its configured upstream resolvers, as expected.\r\n\r\nBecause `dockerd` forwards DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers.\r\n\r\nDocker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.\r\n\r\nMoby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal networks. As a workaround, run containers intended to be solely attached to internal networks with a custom upstream address, which will force all upstream DNS queries to be resolved from the container's network namespace.(CVE-2024-29018)", + "cves": [ + { + "id": "CVE-2024-29018", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29018", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1996": { + "id": "openEuler-SA-2023-1996", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1996", + "title": "An update for mybatis is now available for openEuler-20.03-LTS-SP1", + "severity": "Critical", + "description": "The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor or annotations. Simplicity is the biggest advantage of the MyBatis data mapper over object relational mapping tools. To use the MyBatis data mapper, you rely on your own objects, XML, and SQL. There is little to learn that you don't already know. With the MyBatis data mapper, you have the full power of both SQL and stored procedures at your fingertips. The MyBatis project is developed and maintained by a team that includes the original creators of the \"iBATIS\" data mapper. The Apache project was retired and continued here.\r\n\r\nSecurity Fix(es):\r\n\r\nA SQL injection vulnerability in Mybatis plus below 3.5.3.1 allows remote attackers to execute arbitrary SQL commands via the tenant ID valuer.(CVE-2023-25330)", + "cves": [ + { + "id": "CVE-2023-25330", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25330", + "severity": "Critical" + } + ] + }, + "openEuler-SA-2021-1300": { + "id": "openEuler-SA-2021-1300", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2021-1300", + "title": "An update for curl is now available for openEuler-20.03-LTS-SP1 and openEuler-20.03-LTS-SP2", + "severity": "Medium", + "description": "cURL is a computer software project providing a library (libcurl) and command-line tool (curl) for transferring data using various protocols.\r\n\r\nSecurity Fix(es):\r\n\r\nlibcurl keeps previously used connections in a connection pool for subsequenttransfers to reuse, if one of them matches the setup.Due to errors in the logic, the config matching function did not take 'issuercert' into account and it compared the involved paths *case insensitively*,which could lead to libcurl reusing wrong connections.File paths are, or can be, case sensitive on many systems but not all, and caneven vary depending on used file systems.The comparison also didn't include the 'issuer cert' which a transfer can setto qualify how to verify the server certificate.(CVE-2021-22924)", + "cves": [ + { + "id": "CVE-2021-22924", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22924", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2022-1918": { + "id": "openEuler-SA-2022-1918", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1918", + "title": "An update for qemu is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3 and openEuler-22.03-LTS", + "severity": "Low", + "description": "QEMU is a FAST! processor emulator using dynamic translation to achieve good emulation speed.\n\n\t\tQEMU has two operating modes:\n\n\t\tFull system emulation. In this mode, QEMU emulates a full system (for example a PC),\n\t\tincluding one or several processors and various peripherals. It can be used to launch\n\t\tdifferent Operating Systems without rebooting the PC or to debug system code.\n\n\t\tUser mode emulation. In this mode, QEMU can launch processes compiled for one CPU on another CPU.\n\t\tIt can be used to launch the Wine Windows API emulator (https://www.winehq.org) or to ease\n\t\tcross-compilation and cross-debugging.\n\t\tYou can refer to https://www.qemu.org for more infortmation.\n\r\n\r\nSecurity Fix(es):\r\n\r\nAn infinite loop flaw was found in the USB xHCI controller emulation of QEMU while computing the length of the Transfer Request Block (TRB) Ring. This flaw allows a privileged guest user to hang the QEMU process on the host, resulting in a denial of service.(CVE-2020-14394)", + "cves": [ + { + "id": "CVE-2020-14394", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14394", + "severity": "Low" + } + ] + }, + "openEuler-SA-2024-1791": { + "id": "openEuler-SA-2024-1791", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1791", + "title": "An update for golang is now available for openEuler-24.03-LTS", + "severity": "Medium", + "description": ".\r\n\r\nSecurity Fix(es):\r\n\r\nThe archive/zip package's handling of certain types of invalid zip files differs from the behavior of most zip implementations. This misalignment could be exploited to create an zip file with contents that vary depending on the implementation reading the file. The archive/zip package now rejects files containing these errors.(CVE-2024-24789)", + "cves": [ + { + "id": "CVE-2024-24789", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24789", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2022-1884": { + "id": "openEuler-SA-2022-1884", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1884", + "title": "An update for OpenEXR is now available for openEuler-20.03-LTS-SP1", + "severity": "High", + "description": "OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light & Magic for use in computer imaging applications.\r\n\r\nSecurity Fix(es):\r\n\r\nA flaw was found in OpenEXR's B44Compressor. This flaw allows an attacker who can submit a crafted file to be processed by OpenEXR, to exhaust all memory accessible to the application. The highest threat from this vulnerability is to system availability.(CVE-2021-20298)", + "cves": [ + { + "id": "CVE-2021-20298", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20298", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-2096": { + "id": "openEuler-SA-2022-2096", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-2096", + "title": "An update for xmlrpc is now available for openEuler-22.03-LTS", + "severity": "Critical", + "description": "Apache XML-RPC is a Java implementation of XML-RPC, a popular protocol that uses XML over HTTP to implement remote procedure calls. Apache XML-RPC was previously known as Helma XML-RPC. If you have code using the Helma library, all you should have to do is change the import statements in your code from helma.xmlrpc.* to org.apache.xmlrpc.*.\r\n\r\nSecurity Fix(es):\r\n\r\nAn untrusted deserialization was found in the org.apache.xmlrpc.parser.XmlRpcResponseParser:addResult method of Apache XML-RPC (aka ws-xmlrpc) library. A malicious XML-RPC server could target a XML-RPC client causing it to execute arbitrary code. Apache XML-RPC is no longer maintained and this issue will not be fixed.(CVE-2019-17570)", + "cves": [ + { + "id": "CVE-2019-17570", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17570", + "severity": "Critical" + } + ] + }, + "openEuler-SA-2024-1310": { + "id": "openEuler-SA-2024-1310", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1310", + "title": "An update for qemu is now available for openEuler-22.03-LTS-SP3", + "severity": "Medium", + "description": "QEMU is a FAST! processor emulator using dynamic translation to achieve good emulation speed.\r\n\r\nSecurity Fix(es):\r\n\r\nA DMA reentrancy issue leading to a use-after-free error was found in the e1000e NIC emulation code in QEMU. This issue could allow a privileged guest user to crash the QEMU process on the host, resulting in a denial of service.(CVE-2023-3019)\r\n\r\nA flaw was found in the QEMU built-in VNC server while processing ClientCutText messages. The qemu_clipboard_request() function can be reached before vnc_server_cut_text_caps() was called and had the chance to initialize the clipboard peer, leading to a NULL pointer dereference. This could allow a malicious authenticated VNC client to crash QEMU and trigger a denial of service.(CVE-2023-6683)\r\n\r\nA stack based buffer overflow was found in the virtio-net device of QEMU. This issue occurs when flushing TX in the virtio_net_flush_tx function if guest features VIRTIO_NET_F_HASH_REPORT, VIRTIO_F_VERSION_1 and VIRTIO_NET_F_MRG_RXBUF are enabled. This could allow a malicious user to overwrite local variables allocated on the stack. Specifically, the `out_sg` variable could be used to read a part of process memory and send it to the wire, causing an information leak.(CVE-2023-6693)", + "cves": [ + { + "id": "CVE-2023-6693", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6693", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1726": { + "id": "openEuler-SA-2023-1726", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1726", + "title": "An update for grpc is now available for openEuler-20.03-LTS-SP1", + "severity": "High", + "description": "gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.\r\n\r\nSecurity Fix(es):\r\n\r\nLack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected. (CVE-2023-4785)", + "cves": [ + { + "id": "CVE-2023-4785", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4785", + "severity": "High" + } + ] + }, + "openEuler-SA-2024-1648": { + "id": "openEuler-SA-2024-1648", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1648", + "title": "An update for kernel is now available for openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/slub: fix to return errno if kmalloc() fails\r\n\r\nIn create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to\nout-of-memory, if it fails, return errno correctly rather than\ntriggering panic via BUG_ON();\r\n\r\nkernel BUG at mm/slub.c:5893!\nInternal error: Oops - BUG: 0 [#1] PREEMPT SMP\r\n\r\nCall trace:\n sysfs_slab_add+0x258/0x260 mm/slub.c:5973\n __kmem_cache_create+0x60/0x118 mm/slub.c:4899\n create_cache mm/slab_common.c:229 [inline]\n kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335\n kmem_cache_create+0x1c/0x28 mm/slab_common.c:390\n f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]\n f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808\n f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149\n mount_bdev+0x1b8/0x210 fs/super.c:1400\n f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512\n legacy_get_tree+0x30/0x74 fs/fs_context.c:610\n vfs_get_tree+0x40/0x140 fs/super.c:1530\n do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040\n path_mount+0x358/0x914 fs/namespace.c:3370\n do_mount fs/namespace.c:3383 [inline]\n __do_sys_mount fs/namespace.c:3591 [inline]\n __se_sys_mount fs/namespace.c:3568 [inline]\n __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568(CVE-2022-48659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpiolib: cdev: Set lineevent_state::irq after IRQ register successfully\r\n\r\nWhen running gpio test on nxp-ls1028 platform with below command\ngpiomon --num-events=3 --rising-edge gpiochip1 25\nThere will be a warning trace as below:\nCall trace:\nfree_irq+0x204/0x360\nlineevent_free+0x64/0x70\ngpio_ioctl+0x598/0x6a0\n__arm64_sys_ioctl+0xb4/0x100\ninvoke_syscall+0x5c/0x130\n......\nel0t_64_sync+0x1a0/0x1a4\nThe reason of this issue is that calling request_threaded_irq()\nfunction failed, and then lineevent_free() is invoked to release\nthe resource. Since the lineevent_state::irq was already set, so\nthe subsequent invocation of free_irq() would trigger the above\nwarning call trace. To fix this issue, set the lineevent_state::irq\nafter the IRQ register successfully.(CVE-2022-48660)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix race between mmput() and do_exit()\r\n\r\nTask A calls binder_update_page_range() to allocate and insert pages on\na remote address space from Task B. For this, Task A pins the remote mm\nvia mmget_not_zero() first. This can race with Task B do_exit() and the\nfinal mmput() refcount decrement will come from Task A.\r\n\r\n Task A | Task B\n ------------------+------------------\n mmget_not_zero() |\n | do_exit()\n | exit_mm()\n | mmput()\n mmput() |\n exit_mmap() |\n remove_vma() |\n fput() |\r\n\r\nIn this case, the work of ____fput() from Task B is queued up in Task A\nas TWA_RESUME. So in theory, Task A returns to userspace and the cleanup\nwork gets executed. However, Task A instead sleep, waiting for a reply\nfrom Task B that never comes (it's dead).\r\n\r\nThis means the binder_deferred_release() is blocked until an unrelated\nbinder event forces Task A to go back to userspace. All the associated\ndeath notifications will also be delayed until then.\r\n\r\nIn order to fix this use mmput_async() that will schedule the work in\nthe corresponding mm->async_put_work WQ instead of Task A.(CVE-2023-52609)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwrng: core - Fix page fault dead lock on mmap-ed hwrng\r\n\r\nThere is a dead-lock in the hwrng device read path. This triggers\nwhen the user reads from /dev/hwrng into memory also mmap-ed from\n/dev/hwrng. The resulting page fault triggers a recursive read\nwhich then dead-locks.\r\n\r\nFix this by using a stack buffer when calling copy_to_user.(CVE-2023-52615)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init\r\n\r\nWhen the mpi_ec_ctx structure is initialized, some fields are not\ncleared, causing a crash when referencing the field when the\nstructure was released. Initially, this issue was ignored because\nmemory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.\nFor example, this error will be triggered when calculating the\nZa value for SM2 separately.(CVE-2023-52616)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Check rcu_read_lock_trace_held() before calling bpf map helpers\r\n\r\nThese three bpf_map_{lookup,update,delete}_elem() helpers are also\navailable for sleepable bpf program, so add the corresponding lock\nassertion for sleepable bpf program, otherwise the following warning\nwill be reported when a sleepable bpf program manipulates bpf map under\ninterpreter mode (aka bpf_jit_enable=0):\r\n\r\n WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......\n CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......\n RIP: 0010:bpf_map_lookup_elem+0x54/0x60\n ......\n Call Trace:\n \n ? __warn+0xa5/0x240\n ? bpf_map_lookup_elem+0x54/0x60\n ? report_bug+0x1ba/0x1f0\n ? handle_bug+0x40/0x80\n ? exc_invalid_op+0x18/0x50\n ? asm_exc_invalid_op+0x1b/0x20\n ? __pfx_bpf_map_lookup_elem+0x10/0x10\n ? rcu_lockdep_current_cpu_online+0x65/0xb0\n ? rcu_is_watching+0x23/0x50\n ? bpf_map_lookup_elem+0x54/0x60\n ? __pfx_bpf_map_lookup_elem+0x10/0x10\n ___bpf_prog_run+0x513/0x3b70\n __bpf_prog_run32+0x9d/0xd0\n ? __bpf_prog_enter_sleepable_recur+0xad/0x120\n ? __bpf_prog_enter_sleepable_recur+0x3e/0x120\n bpf_trampoline_6442580665+0x4d/0x1000\n __x64_sys_getpgid+0x5/0x30\n ? do_syscall_64+0x36/0xb0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n (CVE-2023-52621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: Fix a suspicious RCU usage warning\r\n\r\nI received the following warning while running cthon against an ontap\nserver running pNFS:\r\n\r\n[ 57.202521] =============================\n[ 57.202522] WARNING: suspicious RCU usage\n[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted\n[ 57.202525] -----------------------------\n[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!\n[ 57.202527]\n other info that might help us debug this:\r\n\r\n[ 57.202528]\n rcu_scheduler_active = 2, debug_locks = 1\n[ 57.202529] no locks held by test5/3567.\n[ 57.202530]\n stack backtrace:\n[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e\n[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022\n[ 57.202536] Call Trace:\n[ 57.202537] \n[ 57.202540] dump_stack_lvl+0x77/0xb0\n[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0\n[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]\n[ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]\n[ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]\n[ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]\n[ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]\n[ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202866] write_cache_pages+0x265/0x450\n[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202913] do_writepages+0xd2/0x230\n[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80\n[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80\n[ 57.202924] filemap_write_and_wait_range+0xd9/0x170\n[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]\n[ 57.202969] __se_sys_close+0x46/0xd0\n[ 57.202972] do_syscall_64+0x68/0x100\n[ 57.202975] ? do_syscall_64+0x77/0x100\n[ 57.202976] ? do_syscall_64+0x77/0x100\n[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 57.202982] RIP: 0033:0x7fe2b12e4a94\n[ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3\n[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003\n[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94\n[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003\n[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49\n[ 57.202993] R10: 00007f\n---truncated---(CVE-2023-52623)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsh: push-switch: Reorder cleanup operations to avoid use-after-free bug\r\n\r\nThe original code puts flush_work() before timer_shutdown_sync()\nin switch_drv_remove(). Although we use flush_work() to stop\nthe worker, it could be rescheduled in switch_timer(). As a result,\na use-after-free bug can occur. The details are shown below:\r\n\r\n (cpu 0) | (cpu 1)\nswitch_drv_remove() |\n flush_work() |\n ... | switch_timer // timer\n | schedule_work(&psw->work)\n timer_shutdown_sync() |\n ... | switch_work_handler // worker\n kfree(psw) // free |\n | psw->state = 0 // use\r\n\r\nThis patch puts timer_shutdown_sync() before flush_work() to\nmitigate the bugs. As a result, the worker and timer will be\nstopped safely before the deallocate operations.(CVE-2023-52629)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52630)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: time-travel: fix time corruption\r\n\r\nIn 'basic' time-travel mode (without =inf-cpu or =ext), we\nstill get timer interrupts. These can happen at arbitrary\npoints in time, i.e. while in timer_read(), which pushes\ntime forward just a little bit. Then, if we happen to get\nthe interrupt after calculating the new time to push to,\nbut before actually finishing that, the interrupt will set\nthe time to a value that's incompatible with the forward,\nand we'll crash because time goes backwards when we do the\nforwarding.\r\n\r\nFix this by reading the time_travel_time, calculating the\nadjustment, and doing the adjustment all with interrupts\ndisabled.(CVE-2023-52633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPM / devfreq: Synchronize devfreq_monitor_[start/stop]\r\n\r\nThere is a chance if a frequent switch of the governor\ndone in a loop result in timer list corruption where\ntimer cancel being done from two place one from\ncancel_delayed_work_sync() and followed by expire_timers()\ncan be seen from the traces[1].\r\n\r\nwhile true\ndo\n echo \"simple_ondemand\" > /sys/class/devfreq/1d84000.ufshc/governor\n echo \"performance\" > /sys/class/devfreq/1d84000.ufshc/governor\ndone\r\n\r\nIt looks to be issue with devfreq driver where\ndevice_monitor_[start/stop] need to synchronized so that\ndelayed work should get corrupted while it is either\nbeing queued or running or being cancelled.\r\n\r\nLet's use polling flag and devfreq lock to synchronize the\nqueueing the timer instance twice and work data being\ncorrupted.\r\n\r\n[1]\n...\n..\n-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428\n-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c\n-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428\nkworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227\nvendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428\nvendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428\nvendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532\nvendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428\nxxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428\r\n\r\n[2]\r\n\r\n 9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a\n[ 9436.261664][ C4] Mem abort info:\n[ 9436.261666][ C4] ESR = 0x96000044\n[ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 9436.261671][ C4] SET = 0, FnV = 0\n[ 9436.261673][ C4] EA = 0, S1PTW = 0\n[ 9436.261675][ C4] Data abort info:\n[ 9436.261677][ C4] ISV = 0, ISS = 0x00000044\n[ 9436.261680][ C4] CM = 0, WnR = 1\n[ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges\n[ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP\n[ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0\n...\r\n\r\n[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1\n[ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT)\n[ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)\n[ 9436.262161][ C4] pc : expire_timers+0x9c/0x438\n[ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438\n[ 9436.262168][ C4] sp : ffffffc010023dd0\n[ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18\n[ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008\n[ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280\n[ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122\n[ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80\n[ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038\n[ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201\n[ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100\n[ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8\n[ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff\n[ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122\n[ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8\n[ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101\n[ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8\n---truncated---(CVE-2023-52635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)\r\n\r\nLock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)\nmodifies jsk->filters while receiving packets.\r\n\r\nFollowing trace was seen on affected system:\n ==================================================================\n BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n Read of size 4 at addr ffff888012144014 by task j1939/350\r\n\r\n CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n Call Trace:\n print_report+0xd3/0x620\n ? kasan_complete_mode_report_info+0x7d/0x200\n ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n kasan_report+0xc2/0x100\n ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n __asan_load4+0x84/0xb0\n j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n j1939_sk_recv+0x20b/0x320 [can_j1939]\n ? __kasan_check_write+0x18/0x20\n ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]\n ? j1939_simple_recv+0x69/0x280 [can_j1939]\n ? j1939_ac_recv+0x5e/0x310 [can_j1939]\n j1939_can_recv+0x43f/0x580 [can_j1939]\n ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]\n ? raw_rcv+0x42/0x3c0 [can_raw]\n ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]\n can_rcv_filter+0x11f/0x350 [can]\n can_receive+0x12f/0x190 [can]\n ? __pfx_can_rcv+0x10/0x10 [can]\n can_rcv+0xdd/0x130 [can]\n ? __pfx_can_rcv+0x10/0x10 [can]\n __netif_receive_skb_one_core+0x13d/0x150\n ? __pfx___netif_receive_skb_one_core+0x10/0x10\n ? __kasan_check_write+0x18/0x20\n ? _raw_spin_lock_irq+0x8c/0xe0\n __netif_receive_skb+0x23/0xb0\n process_backlog+0x107/0x260\n __napi_poll+0x69/0x310\n net_rx_action+0x2a1/0x580\n ? __pfx_net_rx_action+0x10/0x10\n ? __pfx__raw_spin_lock+0x10/0x10\n ? handle_irq_event+0x7d/0xa0\n __do_softirq+0xf3/0x3f8\n do_softirq+0x53/0x80\n \n \n __local_bh_enable_ip+0x6e/0x70\n netif_rx+0x16b/0x180\n can_send+0x32b/0x520 [can]\n ? __pfx_can_send+0x10/0x10 [can]\n ? __check_object_size+0x299/0x410\n raw_sendmsg+0x572/0x6d0 [can_raw]\n ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]\n ? apparmor_socket_sendmsg+0x2f/0x40\n ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]\n sock_sendmsg+0xef/0x100\n sock_write_iter+0x162/0x220\n ? __pfx_sock_write_iter+0x10/0x10\n ? __rtnl_unlock+0x47/0x80\n ? security_file_permission+0x54/0x320\n vfs_write+0x6ba/0x750\n ? __pfx_vfs_write+0x10/0x10\n ? __fget_light+0x1ca/0x1f0\n ? __rcu_read_unlock+0x5b/0x280\n ksys_write+0x143/0x170\n ? __pfx_ksys_write+0x10/0x10\n ? __kasan_check_read+0x15/0x20\n ? fpregs_assert_state_consistent+0x62/0x70\n __x64_sys_write+0x47/0x60\n do_syscall_64+0x60/0x90\n ? do_syscall_64+0x6d/0x90\n ? irqentry_exit+0x3f/0x50\n ? exc_page_fault+0x79/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\r\n\r\n Allocated by task 348:\n kasan_save_stack+0x2a/0x50\n kasan_set_track+0x29/0x40\n kasan_save_alloc_info+0x1f/0x30\n __kasan_kmalloc+0xb5/0xc0\n __kmalloc_node_track_caller+0x67/0x160\n j1939_sk_setsockopt+0x284/0x450 [can_j1939]\n __sys_setsockopt+0x15c/0x2f0\n __x64_sys_setsockopt+0x6b/0x80\n do_syscall_64+0x60/0x90\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\r\n\r\n Freed by task 349:\n kasan_save_stack+0x2a/0x50\n kasan_set_track+0x29/0x40\n kasan_save_free_info+0x2f/0x50\n __kasan_slab_free+0x12e/0x1c0\n __kmem_cache_free+0x1b9/0x380\n kfree+0x7a/0x120\n j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]\n __sys_setsockopt+0x15c/0x2f0\n __x64_sys_setsockopt+0x6b/0x80\n do_syscall_64+0x60/0x90\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2023-52637)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: s390: vsie: fix race during shadow creation\r\n\r\nRight now it is possible to see gmap->private being zero in\nkvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the\nfact that we add gmap->private == kvm after creation:\r\n\r\nstatic int acquire_gmap_shadow(struct kvm_vcpu *vcpu,\n struct vsie_page *vsie_page)\n{\n[...]\n gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);\n if (IS_ERR(gmap))\n return PTR_ERR(gmap);\n gmap->private = vcpu->kvm;\r\n\r\nLet children inherit the private field of the parent.(CVE-2023-52639)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled\r\n\r\nWhen QoS is disabled, the queue priority value will not map to the correct\nieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS\nis disabled to prevent trying to stop/wake a non-existent queue and failing\nto stop/wake the actual queue instantiated.\r\n\r\nLog of issue before change (with kernel parameter qos=0):\n [ +5.112651] ------------[ cut here ]------------\n [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3\n [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common\n [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]\n [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS\n [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019\n [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00\n [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097\n [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000\n [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900\n [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0\n [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000\n [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40\n [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000\n [ +0.000001] CS: 0010 DS: 0\n---truncated---(CVE-2023-52644)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/imc-pmu: Add a null pointer check in update_events_in_group()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Guard stack limits against 32bit overflow\r\n\r\nThis patch promotes the arithmetic around checking stack bounds to be\ndone in the 64-bit domain, instead of the current 32bit. The arithmetic\nimplies adding together a 64-bit register with a int offset. The\nregister was checked to be below 1<<29 when it was variable, but not\nwhen it was fixed. The offset either comes from an instruction (in which\ncase it is 16 bit), from another register (in which case the caller\nchecked it to be below 1<<29 [1]), or from the size of an argument to a\nkfunc (in which case it can be a u32 [2]). Between the register being\ninconsistently checked to be below 1<<29, and the offset being up to an\nu32, it appears that we were open to overflowing the `int`s which were\ncurrently used for arithmetic.\r\n\r\n[1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498\n[2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904(CVE-2023-52676)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore: ram_core: fix possible overflow in persistent_ram_init_ecc()\r\n\r\nIn persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return\n64-bit value since persistent_ram_zone::buffer_size has type size_t which\nis derived from the 64-bit *unsigned long*, while the ecc_blocks variable\nthis value gets assigned to has (always 32-bit) *int* type. Even if that\nvalue fits into *int* type, an overflow is still possible when calculating\nthe size_t typed ecc_total variable further below since there's no cast to\nany 64-bit type before multiplication. Declaring the ecc_blocks variable\nas *size_t* should fix this mess...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the SVACE static\nanalysis tool.(CVE-2023-52685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/powernv: Add a null pointer check to scom_debug_init_one()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.\nAdd a null pointer check, and release 'ent' to avoid memory leaks.(CVE-2023-52690)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/bridge: tpd12s015: Drop buggy __exit annotation for remove function\r\n\r\nWith tpd12s015_remove() marked with __exit this function is discarded\nwhen the driver is compiled as a built-in. The result is that when the\ndriver unbinds there is no cleanup done which results in resource\nleakage or worse.(CVE-2023-52694)\r\n\r\nA race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.\r\n\r\n\r\n\r\n\n(CVE-2024-24860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: fix a memory corruption\r\n\r\niwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that\nif we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in\nbytes, we'll write past the buffer.(CVE-2024-26610)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()\r\n\r\nsyzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.\r\n\r\nReading frag_off can only be done if we pulled enough bytes\nto skb->head. Currently we might access garbage.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0\nip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0\nipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]\nip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432\n__netdev_start_xmit include/linux/netdevice.h:4940 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4954 [inline]\nxmit_one net/core/dev.c:3548 [inline]\ndev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\ndev_queue_xmit include/linux/netdevice.h:3134 [inline]\nneigh_connected_output+0x569/0x660 net/core/neighbour.c:1592\nneigh_output include/net/neighbour.h:542 [inline]\nip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137\nip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222\nNF_HOOK_COND include/linux/netfilter.h:303 [inline]\nip6_output+0x323/0x610 net/ipv6/ip6_output.c:243\ndst_output include/net/dst.h:451 [inline]\nip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155\nip6_send_skb net/ipv6/ip6_output.c:1952 [inline]\nip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972\nrawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582\nrawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920\ninet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg net/socket.c:745 [inline]\n____sys_sendmsg+0x9c2/0xd60 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/0x490 net/socket.c:2674\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\nslab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\nslab_alloc_node mm/slub.c:3478 [inline]\n__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517\n__do_kmalloc_node mm/slab_common.c:1006 [inline]\n__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027\nkmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\npskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098\n__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655\npskb_may_pull_reason include/linux/skbuff.h:2673 [inline]\npskb_may_pull include/linux/skbuff.h:2681 [inline]\nip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408\nipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]\nip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432\n__netdev_start_xmit include/linux/netdevice.h:4940 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4954 [inline]\nxmit_one net/core/dev.c:3548 [inline]\ndev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\ndev_queue_xmit include/linux/netdevice.h:3134 [inline]\nneigh_connected_output+0x569/0x660 net/core/neighbour.c:1592\nneigh_output include/net/neighbour.h:542 [inline]\nip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137\nip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222\nNF_HOOK_COND include/linux/netfilter.h:303 [inline]\nip6_output+0x323/0x610 net/ipv6/ip6_output.c:243\ndst_output include/net/dst.h:451 [inline]\nip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155\nip6_send_skb net/ipv6/ip6_output.c:1952 [inline]\nip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972\nrawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582\nrawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920\ninet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg net/socket.c:745 [inline]\n____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n__sys_sendmsg net/socket.c:2667 [inline]\n__do_sys_sendms\n---truncated---(CVE-2024-26633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: Drop support for ETH_P_TR_802_2.\r\n\r\nsyzbot reported an uninit-value bug below. [0]\r\n\r\nllc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2\n(0x0011), and syzbot abused the latter to trigger the bug.\r\n\r\n write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', \"90e5dd\"}}}}, 0x16)\r\n\r\nllc_conn_handler() initialises local variables {saddr,daddr}.mac\nbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes\nthem to __llc_lookup().\r\n\r\nHowever, the initialisation is done only when skb->protocol is\nhtons(ETH_P_802_2), otherwise, __llc_lookup_established() and\n__llc_lookup_listener() will read garbage.\r\n\r\nThe missing initialisation existed prior to commit 211ed865108e\n(\"net: delete all instances of special processing for token ring\").\r\n\r\nIt removed the part to kick out the token ring stuff but forgot to\nclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().\r\n\r\nLet's remove llc_tr_packet_type and complete the deprecation.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90\n __llc_lookup_established+0xe9d/0xf90\n __llc_lookup net/llc/llc_conn.c:611 [inline]\n llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\n __netif_receive_skb_one_core net/core/dev.c:5527 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641\n netif_receive_skb_internal net/core/dev.c:5727 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5786\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x8ef/0x1490 fs/read_write.c:584\n ksys_write+0x20f/0x4c0 fs/read_write.c:637\n __do_sys_write fs/read_write.c:649 [inline]\n __se_sys_write fs/read_write.c:646 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:646\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nLocal variable daddr created at:\n llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\r\n\r\nCPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: make llc_ui_sendmsg() more robust against bonding changes\r\n\r\nsyzbot was able to trick llc_ui_sendmsg(), allocating an skb with no\nheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]\r\n\r\nLike some others, llc_ui_sendmsg() releases the socket lock before\ncalling sock_alloc_send_skb().\nThen it acquires it again, but does not redo all the sanity checks\nthat were performed.\r\n\r\nThis fix:\r\n\r\n- Uses LL_RESERVED_SPACE() to reserve space.\n- Check all conditions again after socket lock is held again.\n- Do not account Ethernet header for mtu limitation.\r\n\r\n[1]\r\n\r\nskbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0\r\n\r\n kernel BUG at net/core/skbuff.c:193 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : skb_panic net/core/skbuff.c:189 [inline]\n pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n lr : skb_panic net/core/skbuff.c:189 [inline]\n lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\nsp : ffff800096f97000\nx29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000\nx26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2\nx23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0\nx20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce\nx17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001\nx14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400\nx8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714\nx2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089\nCall trace:\n skb_panic net/core/skbuff.c:189 [inline]\n skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n skb_push+0xf0/0x108 net/core/skbuff.c:2451\n eth_header+0x44/0x1f8 net/ethernet/eth.c:83\n dev_hard_header include/linux/netdevice.h:3188 [inline]\n llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33\n llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85\n llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209\n llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270\n llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x194/0x274 net/socket.c:767\n splice_to_socket+0x7cc/0xd58 fs/splice.c:881\n do_splice_from fs/splice.c:933 [inline]\n direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142\n splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088\n do_splice_direct+0x20c/0x348 fs/splice.c:1194\n do_sendfile+0x4bc/0xc70 fs/read_write.c:1254\n __do_sys_sendfile64 fs/read_write.c:1322 [inline]\n __se_sys_sendfile64 fs/read_write.c:1308 [inline]\n __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308\n __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\n el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595\nCode: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: add sanity checks to rx zerocopy\r\n\r\nTCP rx zerocopy intent is to map pages initially allocated\nfrom NIC drivers, not pages owned by a fs.\r\n\r\nThis patch adds to can_map_frag() these additional checks:\r\n\r\n- Page must not be a compound one.\n- page->mapping must be NULL.\r\n\r\nThis fixes the panic reported by ZhangPeng.\r\n\r\nsyzbot was able to loopback packets built with sendfile(),\nmapping pages owned by an ext4 file to TCP rx zerocopy.\r\n\r\nr3 = socket$inet_tcp(0x2, 0x1, 0x0)\nmmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)\nr4 = socket$inet_tcp(0x2, 0x1, 0x0)\nbind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)\nconnect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)\nr5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\\x00',\n 0x181e42, 0x0)\nfallocate(r5, 0x0, 0x0, 0x85b8)\nsendfile(r4, r5, 0x0, 0x8ba0)\ngetsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,\n &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,\n 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)\nr6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\\x00',\n 0x181e42, 0x0)(CVE-2024-26640)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\r\n\r\nsyzbot found __ip6_tnl_rcv() could access unitiliazed data [1].\r\n\r\nCall pskb_inet_may_pull() to fix this, and initialize ipv6h\nvariable after this call as it can change skb->head.\r\n\r\n[1]\n BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727\n __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845\n ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888\n gre_rcv+0x143f/0x1870\n ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438\n ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n dst_input include/net/dst.h:461 [inline]\n ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core net/core/dev.c:5532 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646\n netif_receive_skb_internal net/core/dev.c:5732 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5791\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787\n tun_alloc_skb drivers/net/tun.c:1531 [inline]\n tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: disallow anonymous set with timeout flag\r\n\r\nAnonymous sets are never used with timeout from userspace, reject this.\nException to this rule is NFT_SET_EVAL to ensure legacy meters still work.(CVE-2024-26642)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Ensure visibility when inserting an element into tracing_map\r\n\r\nRunning the following two commands in parallel on a multi-processor\nAArch64 machine can sporadically produce an unexpected warning about\nduplicate histogram entries:\r\n\r\n $ while true; do\n echo hist:key=id.syscall:val=hitcount > \\\n /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger\n cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist\n sleep 0.001\n done\n $ stress-ng --sysbadaddr $(nproc)\r\n\r\nThe warning looks as follows:\r\n\r\n[ 2911.172474] ------------[ cut here ]------------\n[ 2911.173111] Duplicates detected: 1\n[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408\n[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)\n[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1\n[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01\n[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018\n[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408\n[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408\n[ 2911.185310] sp : ffff8000a1513900\n[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001\n[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008\n[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180\n[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff\n[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8\n[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731\n[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c\n[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8\n[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000\n[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480\n[ 2911.194259] Call trace:\n[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408\n[ 2911.195220] hist_show+0x124/0x800\n[ 2911.195692] seq_read_iter+0x1d4/0x4e8\n[ 2911.196193] seq_read+0xe8/0x138\n[ 2911.196638] vfs_read+0xc8/0x300\n[ 2911.197078] ksys_read+0x70/0x108\n[ 2911.197534] __arm64_sys_read+0x24/0x38\n[ 2911.198046] invoke_syscall+0x78/0x108\n[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8\n[ 2911.199157] do_el0_svc+0x28/0x40\n[ 2911.199613] el0_svc+0x40/0x178\n[ 2911.200048] el0t_64_sync_handler+0x13c/0x158\n[ 2911.200621] el0t_64_sync+0x1a8/0x1b0\n[ 2911.201115] ---[ end trace 0000000000000000 ]---\r\n\r\nThe problem appears to be caused by CPU reordering of writes issued from\n__tracing_map_insert().\r\n\r\nThe check for the presence of an element with a given key in this\nfunction is:\r\n\r\n val = READ_ONCE(entry->val);\n if (val && keys_match(key, val->key, map->key_size)) ...\r\n\r\nThe write of a new entry is:\r\n\r\n elt = get_free_elt(map);\n memcpy(elt->key, key, map->key_size);\n entry->val = elt;\r\n\r\nThe \"memcpy(elt->key, key, map->key_size);\" and \"entry->val = elt;\"\nstores may become visible in the reversed order on another CPU. This\nsecond CPU might then incorrectly determine that a new key doesn't match\nan already present val->key and subse\n---truncated---(CVE-2024-26645)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'\r\n\r\nIn \"u32 otg_inst = pipe_ctx->stream_res.tg->inst;\"\npipe_ctx->stream_res.tg could be NULL, it is relying on the caller to\nensure the tg is not NULL.(CVE-2024-26661)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntunnels: fix out of bounds access when building IPv6 PMTU error\r\n\r\nIf the ICMPv6 error is built from a non-linear skb we get the following\nsplat,\r\n\r\n BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240\n Read of size 4 at addr ffff88811d402c80 by task netperf/820\n CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543\n ...\n kasan_report+0xd8/0x110\n do_csum+0x220/0x240\n csum_partial+0xc/0x20\n skb_tunnel_check_pmtu+0xeb9/0x3280\n vxlan_xmit_one+0x14c2/0x4080\n vxlan_xmit+0xf61/0x5c00\n dev_hard_start_xmit+0xfb/0x510\n __dev_queue_xmit+0x7cd/0x32a0\n br_dev_queue_push_xmit+0x39d/0x6a0\r\n\r\nUse skb_checksum instead of csum_partial who cannot deal with non-linear\nSKBs.(CVE-2024-26665)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nppp_async: limit MRU to 64K\r\n\r\nsyzbot triggered a warning [1] in __alloc_pages():\r\n\r\nWARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)\r\n\r\nWillem fixed a similar issue in commit c0a2a1b0d631 (\"ppp: limit MRU to 64K\")\r\n\r\nAdopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)\r\n\r\n[1]:\r\n\r\n WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543\nModules linked in:\nCPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\nWorkqueue: events_unbound flush_to_ldisc\npstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543\n lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537\nsp : ffff800093967580\nx29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000\nx26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0\nx23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8\nx20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120\nx17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005\nx14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000\nx11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001\nx8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f\nx5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020\nx2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0\nCall trace:\n __alloc_pages+0x308/0x698 mm/page_alloc.c:4543\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926\n __do_kmalloc_node mm/slub.c:3969 [inline]\n __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001\n kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590\n __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651\n __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715\n netdev_alloc_skb include/linux/skbuff.h:3235 [inline]\n dev_alloc_skb include/linux/skbuff.h:3248 [inline]\n ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]\n ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341\n tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390\n tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37\n receive_buf drivers/tty/tty_buffer.c:444 [inline]\n flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494\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(CVE-2024-26675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet: read sk->sk_family once in inet_recv_error()\r\n\r\ninet_recv_error() is called without holding the socket lock.\r\n\r\nIPv6 socket could mutate to IPv4 with IPV6_ADDRFORM\nsocket option and trigger a KCSAN warning.(CVE-2024-26679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: stmmac: xgmac: fix handling of DPP safety error for DMA channels\r\n\r\nCommit 56e58d6c8a56 (\"net: stmmac: Implement Safety Features in\nXGMAC core\") checks and reports safety errors, but leaves the\nData Path Parity Errors for each channel in DMA unhandled at all, lead to\na storm of interrupt.\nFix it by checking and clearing the DMA_DPP_Interrupt_Status register.(CVE-2024-26684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential bug in end_buffer_async_write\r\n\r\nAccording to a syzbot report, end_buffer_async_write(), which handles the\ncompletion of block device writes, may detect abnormal condition of the\nbuffer async_write flag and cause a BUG_ON failure when using nilfs2.\r\n\r\nNilfs2 itself does not use end_buffer_async_write(). But, the async_write\nflag is now used as a marker by commit 7f42ec394156 (\"nilfs2: fix issue\nwith race condition of competition between segments for dirty blocks\") as\na means of resolving double list insertion of dirty blocks in\nnilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the\nresulting crash.\r\n\r\nThis modification is safe as long as it is used for file data and b-tree\nnode blocks where the page caches are independent. However, it was\nirrelevant and redundant to also introduce async_write for segment summary\nand super root blocks that share buffers with the backing device. This\nled to the possibility that the BUG_ON check in end_buffer_async_write\nwould fail as described above, if independent writebacks of the backing\ndevice occurred in parallel.\r\n\r\nThe use of async_write for segment summary buffers has already been\nremoved in a previous change.\r\n\r\nFix this issue by removing the manipulation of the async_write flag for\nthe remaining super root block buffer.(CVE-2024-26685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats\r\n\r\nlock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call\ndo_task_stat() at the same time and the process has NR_THREADS, it will\nspin with irqs disabled O(NR_CPUS * NR_THREADS) time.\r\n\r\nChange do_task_stat() to use sig->stats_lock to gather the statistics\noutside of ->siglock protected section, in the likely case this code will\nrun lockless.(CVE-2024-26686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix data corruption in dsync block recovery for small block sizes\r\n\r\nThe helper function nilfs_recovery_copy_block() of\nnilfs_recovery_dsync_blocks(), which recovers data from logs created by\ndata sync writes during a mount after an unclean shutdown, incorrectly\ncalculates the on-page offset when copying repair data to the file's page\ncache. In environments where the block size is smaller than the page\nsize, this flaw can cause data corruption and leak uninitialized memory\nbytes during the recovery process.\r\n\r\nFix these issues by correcting this byte offset calculation on the page.(CVE-2024-26697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC\r\n\r\nRecently, we encounter kernel crash in function rm3100_common_probe\ncaused by out of bound access of array rm3100_samp_rates (because of\nunderlying hardware failures). Add boundary check to prevent out of\nbound access.(CVE-2024-26702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nparisc: Fix random data corruption from exception handler\r\n\r\nThe current exception handler implementation, which assists when accessing\nuser space memory, may exhibit random data corruption if the compiler decides\nto use a different register than the specified register %r29 (defined in\nASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another\nregister, the fault handler will nevertheless store -EFAULT into %r29 and thus\ntrash whatever this register is used for.\nLooking at the assembly I found that this happens sometimes in emulate_ldd().\r\n\r\nTo solve the issue, the easiest solution would be if it somehow is\npossible to tell the fault handler which register is used to hold the error\ncode. Using %0 or %1 in the inline assembly is not posssible as it will show\nup as e.g. %r29 (with the \"%r\" prefix), which the GNU assembler can not\nconvert to an integer.\r\n\r\nThis patch takes another, better and more flexible approach:\nWe extend the __ex_table (which is out of the execution path) by one 32-word.\nIn this word we tell the compiler to insert the assembler instruction\n\"or %r0,%r0,%reg\", where %reg references the register which the compiler\nchoosed for the error return code.\nIn case of an access failure, the fault handler finds the __ex_table entry and\ncan examine the opcode. The used register is encoded in the lowest 5 bits, and\nthe fault handler can then store -EFAULT into this register.\r\n\r\nSince we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT\nconfig option any longer.(CVE-2024-26706)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()\r\n\r\nSyzkaller reported [1] hitting a warning after failing to allocate\nresources for skb in hsr_init_skb(). Since a WARN_ONCE() call will\nnot help much in this case, it might be prudent to switch to\nnetdev_warn_once(). At the very least it will suppress syzkaller\nreports such as [1].\r\n\r\nJust in case, use netdev_warn_once() in send_prp_supervision_frame()\nfor similar reasons.\r\n\r\n[1]\nHSR: Could not send supervision frame\nWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294\nRIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294\n...\nCall Trace:\n \n hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382\n call_timer_fn+0x193/0x590 kernel/time/timer.c:1700\n expire_timers kernel/time/timer.c:1751 [inline]\n __run_timers+0x764/0xb20 kernel/time/timer.c:2022\n run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035\n __do_softirq+0x21a/0x8de kernel/softirq.c:553\n invoke_softirq kernel/softirq.c:427 [inline]\n __irq_exit_rcu kernel/softirq.c:632 [inline]\n irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644\n sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076\n \n \n asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649\n...\r\n\r\nThis issue is also found in older kernels (at least up to 5.10).(CVE-2024-26707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/kasan: Fix addr error caused by page alignment\r\n\r\nIn kasan_init_region, when k_start is not page aligned, at the begin of\nfor loop, k_cur = k_start & PAGE_MASK is less than k_start, and then\n`va = block + k_cur - k_start` is less than block, the addr va is invalid,\nbecause the memory address space from va to block is not alloced by\nmemblock_alloc, which will not be reserved by memblock_reserve later, it\nwill be used by other places.\r\n\r\nAs a result, memory overwriting occurs.\r\n\r\nfor example:\nint __init __weak kasan_init_region(void *start, size_t size)\n{\n[...]\n\t/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */\n\tblock = memblock_alloc(k_end - k_start, PAGE_SIZE);\n\t[...]\n\tfor (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {\n\t\t/* at the begin of for loop\n\t\t * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)\n\t\t * va(dcd96c00) is less than block(dcd97000), va is invalid\n\t\t */\n\t\tvoid *va = block + k_cur - k_start;\n\t\t[...]\n\t}\n[...]\n}\r\n\r\nTherefore, page alignment is performed on k_start before\nmemblock_alloc() to ensure the validity of the VA address.(CVE-2024-26712)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again\r\n\r\n(struct dirty_throttle_control *)->thresh is an unsigned long, but is\npassed as the u32 divisor argument to div_u64(). On architectures where\nunsigned long is 64 bytes, the argument will be implicitly truncated.\r\n\r\nUse div64_u64() instead of div_u64() so that the value used in the \"is\nthis a safe division\" check is the same as the divisor.\r\n\r\nAlso, remove redundant cast of the numerator to u64, as that should happen\nimplicitly.\r\n\r\nThis would be difficult to exploit in memcg domain, given the ratio-based\narithmetic domain_drity_limits() uses, but is much easier in global\nwriteback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. \nvm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32)(CVE-2024-26720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don't drop extent_map for free space inode on write error\r\n\r\nWhile running the CI for an unrelated change I hit the following panic\nwith generic/648 on btrfs_holes_spacecache.\r\n\r\nassertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385\n------------[ cut here ]------------\nkernel BUG at fs/btrfs/extent_io.c:1385!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1\nRIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0\nCall Trace:\n \n extent_write_cache_pages+0x2ac/0x8f0\n extent_writepages+0x87/0x110\n do_writepages+0xd5/0x1f0\n filemap_fdatawrite_wbc+0x63/0x90\n __filemap_fdatawrite_range+0x5c/0x80\n btrfs_fdatawrite_range+0x1f/0x50\n btrfs_write_out_cache+0x507/0x560\n btrfs_write_dirty_block_groups+0x32a/0x420\n commit_cowonly_roots+0x21b/0x290\n btrfs_commit_transaction+0x813/0x1360\n btrfs_sync_file+0x51a/0x640\n __x64_sys_fdatasync+0x52/0x90\n do_syscall_64+0x9c/0x190\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nThis happens because we fail to write out the free space cache in one\ninstance, come back around and attempt to write it again. However on\nthe second pass through we go to call btrfs_get_extent() on the inode to\nget the extent mapping. Because this is a new block group, and with the\nfree space inode we always search the commit root to avoid deadlocking\nwith the tree, we find nothing and return a EXTENT_MAP_HOLE for the\nrequested range.\r\n\r\nThis happens because the first time we try to write the space cache out\nwe hit an error, and on an error we drop the extent mapping. This is\nnormal for normal files, but the free space cache inode is special. We\nalways expect the extent map to be correct. Thus the second time\nthrough we end up with a bogus extent map.\r\n\r\nSince we're deprecating this feature, the most straightforward way to\nfix this is to simply skip dropping the extent map range for this failed\nrange.\r\n\r\nI shortened the test by using error injection to stress the area to make\nit easier to reproduce. With this patch in place we no longer panic\nwith my error injection test.(CVE-2024-26726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narp: Prevent overflow in arp_req_get().\r\n\r\nsyzkaller reported an overflown write in arp_req_get(). [0]\r\n\r\nWhen ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour\nentry and copies neigh->ha to struct arpreq.arp_ha.sa_data.\r\n\r\nThe arp_ha here is struct sockaddr, not struct sockaddr_storage, so\nthe sa_data buffer is just 14 bytes.\r\n\r\nIn the splat below, 2 bytes are overflown to the next int field,\narp_flags. We initialise the field just after the memcpy(), so it's\nnot a problem.\r\n\r\nHowever, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),\narp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)\nin arp_ioctl() before calling arp_req_get().\r\n\r\nTo avoid the overflow, let's limit the max length of memcpy().\r\n\r\nNote that commit b5f0de6df6dc (\"net: dev: Convert sa_data to flexible\narray in struct sockaddr\") just silenced syzkaller.\r\n\r\n[0]:\nmemcpy: detected field-spanning write (size 16) of single field \"r->arp_ha.sa_data\" at net/ipv4/arp.c:1128 (size 14)\nWARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nModules linked in:\nCPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014\nRIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nCode: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6\nRSP: 0018:ffffc900050b7998 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001\nRBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000\nR13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010\nFS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \n arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261\n inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981\n sock_do_ioctl+0xdf/0x260 net/socket.c:1204\n sock_ioctl+0x3ef/0x650 net/socket.c:1321\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x64/0xce\nRIP: 0033:0x7f172b262b8d\nCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d\nRDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003\nRBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000\n (CVE-2024-26733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevlink: fix possible use-after-free and memory leaks in devlink_init()\r\n\r\nThe pernet operations structure for the subsystem must be registered\nbefore registering the generic netlink family.\r\n\r\nMake an unregister in case of unsuccessful registration.(CVE-2024-26734)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix possible use-after-free and null-ptr-deref\r\n\r\nThe pernet operations structure for the subsystem must be registered\nbefore registering the generic netlink family.(CVE-2024-26735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_mirred: use the backlog for mirred ingress\r\n\r\nThe test Davide added in commit ca22da2fbd69 (\"act_mirred: use the backlog\nfor nested calls to mirred ingress\") hangs our testing VMs every 10 or so\nruns, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by\nlockdep.\r\n\r\nThe problem as previously described by Davide (see Link) is that\nif we reverse flow of traffic with the redirect (egress -> ingress)\nwe may reach the same socket which generated the packet. And we may\nstill be holding its socket lock. The common solution to such deadlocks\nis to put the packet in the Rx backlog, rather than run the Rx path\ninline. Do that for all egress -> ingress reversals, not just once\nwe started to nest mirred calls.\r\n\r\nIn the past there was a concern that the backlog indirection will\nlead to loss of error reporting / less accurate stats. But the current\nworkaround does not seem to address the issue.(CVE-2024-26740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/qedr: Fix qedr_create_user_qp error flow\r\n\r\nAvoid the following warning by making sure to free the allocated\nresources in case that qedr_init_user_queue() fail.\r\n\r\n-----------[ cut here ]-----------\nWARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nModules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3\nghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]\nCPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1\nHardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022\nRIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nCode: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff\nRSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286\nRAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016\nRDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600\nRBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80\nR13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0\nCall Trace:\n\n? show_trace_log_lvl+0x1c4/0x2df\n? show_trace_log_lvl+0x1c4/0x2df\n? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\n? __warn+0x81/0x110\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\n? report_bug+0x10a/0x140\n? handle_bug+0x3c/0x70\n? exc_invalid_op+0x14/0x70\n? asm_exc_invalid_op+0x16/0x20\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nib_uverbs_close+0x1f/0xb0 [ib_uverbs]\n__fput+0x94/0x250\ntask_work_run+0x5c/0x90\ndo_exit+0x270/0x4a0\ndo_group_exit+0x2d/0x90\nget_signal+0x87c/0x8c0\narch_do_signal_or_restart+0x25/0x100\n? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]\nexit_to_user_mode_loop+0x9c/0x130\nexit_to_user_mode_prepare+0xb6/0x100\nsyscall_exit_to_user_mode+0x12/0x40\ndo_syscall_64+0x69/0x90\n? syscall_exit_work+0x103/0x130\n? syscall_exit_to_user_mode+0x22/0x40\n? do_syscall_64+0x69/0x90\n? syscall_exit_work+0x103/0x130\n? syscall_exit_to_user_mode+0x22/0x40\n? do_syscall_64+0x69/0x90\n? do_syscall_64+0x69/0x90\n? common_interrupt+0x43/0xa0\nentry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x1470abe3ec6b\nCode: Unable to access opcode bytes at RIP 0x1470abe3ec41.\nRSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b\nRDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004\nRBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00\nR10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358\nR13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470\n\n--[ end trace 888a9b92e04c5c97 ]--(CVE-2024-26743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/srpt: Support specifying the srpt_service_guid parameter\r\n\r\nMake loading ib_srpt with this parameter set work. The current behavior is\nthat setting that parameter while loading the ib_srpt kernel module\ntriggers the following kernel crash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nCall Trace:\n \n parse_one+0x18c/0x1d0\n parse_args+0xe1/0x230\n load_module+0x8de/0xa60\n init_module_from_file+0x8b/0xd0\n idempotent_init_module+0x181/0x240\n __x64_sys_finit_module+0x5a/0xb0\n do_syscall_64+0x5f/0xe0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76(CVE-2024-26744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()\r\n\r\nThe gtp_net_ops pernet operations structure for the subsystem must be\nregistered before registering the generic netlink family.\r\n\r\nSyzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:\r\n\r\ngeneral protection fault, probably for non-canonical address\n0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\nCPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\nRIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]\nCode: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86\n df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>\n 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74\nRSP: 0018:ffff888014107220 EFLAGS: 00010202\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000\nFS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \n ? show_regs+0x90/0xa0\n ? die_addr+0x50/0xd0\n ? exc_general_protection+0x148/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? gtp_genl_dump_pdp+0x1be/0x800 [gtp]\n ? __alloc_skb+0x1dd/0x350\n ? __pfx___alloc_skb+0x10/0x10\n genl_dumpit+0x11d/0x230\n netlink_dump+0x5b9/0xce0\n ? lockdep_hardirqs_on_prepare+0x253/0x430\n ? __pfx_netlink_dump+0x10/0x10\n ? kasan_save_track+0x10/0x40\n ? __kasan_kmalloc+0x9b/0xa0\n ? genl_start+0x675/0x970\n __netlink_dump_start+0x6fc/0x9f0\n genl_family_rcv_msg_dumpit+0x1bb/0x2d0\n ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10\n ? genl_op_from_small+0x2a/0x440\n ? cap_capable+0x1d0/0x240\n ? __pfx_genl_start+0x10/0x10\n ? __pfx_genl_dumpit+0x10/0x10\n ? __pfx_genl_done+0x10/0x10\n ? security_capable+0x9d/0xe0(CVE-2024-26754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm-crypt: don't modify the data when using authenticated encryption\r\n\r\nIt was said that authenticated encryption could produce invalid tag when\nthe data that is being encrypted is modified [1]. So, fix this problem by\ncopying the data into the clone bio first and then encrypt them inside the\nclone bio.\r\n\r\nThis may reduce performance, but it is needed to prevent the user from\ncorrupting the device by writing data with O_DIRECT and modifying them at\nthe same time.\r\n\r\n[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/(CVE-2024-26763)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected\r\n\r\nReturn IRQ_NONE from the interrupt handler when no interrupt was\ndetected. Because an empty interrupt will cause a null pointer error:\r\n\r\n Unable to handle kernel NULL pointer dereference at virtual\n address 0000000000000008\n Call trace:\n complete+0x54/0x100\n hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]\n __handle_irq_event_percpu+0x64/0x1e0\n handle_irq_event+0x7c/0x1cc(CVE-2024-26776)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: fix double-free on socket dismantle\r\n\r\nwhen MPTCP server accepts an incoming connection, it clones its listener\nsocket. However, the pointer to 'inet_opt' for the new socket has the same\nvalue as the original one: as a consequence, on program exit it's possible\nto observe the following splat:\r\n\r\n BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0\n Free of addr ffff888485950880 by task swapper/25/0\r\n\r\n CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609\n Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013\n Call Trace:\n \n dump_stack_lvl+0x32/0x50\n print_report+0xca/0x620\n kasan_report_invalid_free+0x64/0x90\n __kasan_slab_free+0x1aa/0x1f0\n kfree+0xed/0x2e0\n inet_sock_destruct+0x54f/0x8b0\n __sk_destruct+0x48/0x5b0\n rcu_do_batch+0x34e/0xd90\n rcu_core+0x559/0xac0\n __do_softirq+0x183/0x5a4\n irq_exit_rcu+0x12d/0x170\n sysvec_apic_timer_interrupt+0x6b/0x80\n \n \n asm_sysvec_apic_timer_interrupt+0x16/0x20\n RIP: 0010:cpuidle_enter_state+0x175/0x300\n Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b\n RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202\n RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000\n RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588\n RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080\n R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0\n R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80\n cpuidle_enter+0x4a/0xa0\n do_idle+0x310/0x410\n cpu_startup_entry+0x51/0x60\n start_secondary+0x211/0x270\n secondary_startup_64_no_verify+0x184/0x18b\n \r\n\r\n Allocated by task 6853:\n kasan_save_stack+0x1c/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0xa6/0xb0\n __kmalloc+0x1eb/0x450\n cipso_v4_sock_setattr+0x96/0x360\n netlbl_sock_setattr+0x132/0x1f0\n selinux_netlbl_socket_post_create+0x6c/0x110\n selinux_socket_post_create+0x37b/0x7f0\n security_socket_post_create+0x63/0xb0\n __sock_create+0x305/0x450\n __sys_socket_create.part.23+0xbd/0x130\n __sys_socket+0x37/0xb0\n __x64_sys_socket+0x6f/0xb0\n do_syscall_64+0x83/0x160\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\n Freed by task 6858:\n kasan_save_stack+0x1c/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x12c/0x1f0\n kfree+0xed/0x2e0\n inet_sock_destruct+0x54f/0x8b0\n __sk_destruct+0x48/0x5b0\n subflow_ulp_release+0x1f0/0x250\n tcp_cleanup_ulp+0x6e/0x110\n tcp_v4_destroy_sock+0x5a/0x3a0\n inet_csk_destroy_sock+0x135/0x390\n tcp_fin+0x416/0x5c0\n tcp_data_queue+0x1bc8/0x4310\n tcp_rcv_state_process+0x15a3/0x47b0\n tcp_v4_do_rcv+0x2c1/0x990\n tcp_v4_rcv+0x41fb/0x5ed0\n ip_protocol_deliver_rcu+0x6d/0x9f0\n ip_local_deliver_finish+0x278/0x360\n ip_local_deliver+0x182/0x2c0\n ip_rcv+0xb5/0x1c0\n __netif_receive_skb_one_core+0x16e/0x1b0\n process_backlog+0x1e3/0x650\n __napi_poll+0xa6/0x500\n net_rx_action+0x740/0xbb0\n __do_softirq+0x183/0x5a4\r\n\r\n The buggy address belongs to the object at ffff888485950880\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes inside of\n 64-byte region [ffff888485950880, ffff8884859508c0)\r\n\r\n The buggy address belongs to the physical page:\n page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950\n flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)\n page_type: 0xffffffff()\n raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006\n raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\r\n\r\n Memory state around the buggy address:\n ffff888485950780: fa fb fb\n---truncated---(CVE-2024-26782)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmci: stm32: fix DMA API overlapping mappings warning\r\n\r\nTurning on CONFIG_DMA_API_DEBUG_SG results in the following warning:\r\n\r\nDMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,\noverlapping mappings aren't supported\nWARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568\nadd_dma_entry+0x234/0x2f4\nModules linked in:\nCPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1\nHardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)\nWorkqueue: events_freezable mmc_rescan\nCall trace:\nadd_dma_entry+0x234/0x2f4\ndebug_dma_map_sg+0x198/0x350\n__dma_map_sg_attrs+0xa0/0x110\ndma_map_sg_attrs+0x10/0x2c\nsdmmc_idma_prep_data+0x80/0xc0\nmmci_prep_data+0x38/0x84\nmmci_start_data+0x108/0x2dc\nmmci_request+0xe4/0x190\n__mmc_start_request+0x68/0x140\nmmc_start_request+0x94/0xc0\nmmc_wait_for_req+0x70/0x100\nmmc_send_tuning+0x108/0x1ac\nsdmmc_execute_tuning+0x14c/0x210\nmmc_execute_tuning+0x48/0xec\nmmc_sd_init_uhs_card.part.0+0x208/0x464\nmmc_sd_init_card+0x318/0x89c\nmmc_attach_sd+0xe4/0x180\nmmc_rescan+0x244/0x320\r\n\r\nDMA API debug brings to light leaking dma-mappings as dma_map_sg and\ndma_unmap_sg are not correctly balanced.\r\n\r\nIf an error occurs in mmci_cmd_irq function, only mmci_dma_error\nfunction is called and as this API is not managed on stm32 variant,\ndma_unmap_sg is never called in this error path.(CVE-2024-26787)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: Avoid potential use-after-free in hci_error_reset\r\n\r\nWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlying\nBT controller is not responding, the GPIO reset mechanism would\nfree the hci_dev and lead to a use-after-free in hci_error_reset.\r\n\r\nHere's the call trace observed on a ChromeOS device with Intel AX201:\n queue_work_on+0x3e/0x6c\n __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ]\n ? init_wait_entry+0x31/0x31\n __hci_cmd_sync+0x16/0x20 [bluetooth ]\n hci_error_reset+0x4f/0xa4 [bluetooth ]\n process_one_work+0x1d8/0x33f\n worker_thread+0x21b/0x373\n kthread+0x13a/0x152\n ? pr_cont_work+0x54/0x54\n ? kthread_blkcg+0x31/0x31\n ret_from_fork+0x1f/0x30\r\n\r\nThis patch holds the reference count on the hci_dev while processing\na HCI_EV_HARDWARE_ERROR event to avoid potential crash.(CVE-2024-26801)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetlink: Fix kernel-infoleak-after-free in __skb_datagram_iter\r\n\r\nsyzbot reported the following uninit-value access issue [1]:\r\n\r\nnetlink_to_full_skb() creates a new `skb` and puts the `skb->data`\npassed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data\nsize is specified as `len` and passed to skb_put_data(). This `len`\nis based on `skb->end` that is not data offset but buffer offset. The\n`skb->end` contains data and tailroom. Since the tailroom is not\ninitialized when the new `skb` created, KMSAN detects uninitialized\nmemory area when copying the data.\r\n\r\nThis patch resolved this issue by correct the len from `skb->end` to\n`skb->len`, which is the actual data offset.\r\n\r\nBUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186\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+0x364/0x2520 lib/iov_iter.c:186\n copy_to_iter include/linux/uio.h:197 [inline]\n simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532\n __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420\n skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546\n skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]\n packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482\n sock_recvmsg_nosec net/socket.c:1044 [inline]\n sock_recvmsg net/socket.c:1066 [inline]\n sock_read_iter+0x467/0x580 net/socket.c:1136\n call_read_iter include/linux/fs.h:2014 [inline]\n new_sync_read fs/read_write.c:389 [inline]\n vfs_read+0x8f6/0xe00 fs/read_write.c:470\n ksys_read+0x20f/0x4c0 fs/read_write.c:613\n __do_sys_read fs/read_write.c:623 [inline]\n __se_sys_read fs/read_write.c:621 [inline]\n __x64_sys_read+0x93/0xd0 fs/read_write.c:621\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was stored to memory at:\n skb_put_data include/linux/skbuff.h:2622 [inline]\n netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]\n __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]\n __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325\n netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]\n netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 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/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n free_pages_prepare mm/page_alloc.c:1087 [inline]\n free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347\n free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533\n release_pages+0x23d3/0x2410 mm/swap.c:1042\n free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316\n tlb_batch_pages\n---truncated---(CVE-2024-26805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain\r\n\r\nRemove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER\nevent is reported, otherwise a stale reference to netdevice remains in\nthe hook list.(CVE-2024-26808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: release elements in clone only from destroy path\r\n\r\nClone already always provides a current view of the lookup table, use it\nto destroy the set, otherwise it is possible to destroy elements twice.\r\n\r\nThis fix requires:\r\n\r\n 212ed75dc5fb (\"netfilter: nf_tables: integrate pipapo into commit protocol\")\r\n\r\nwhich came after:\r\n\r\n 9827a0e6e23b (\"netfilter: nft_set_pipapo: release elements in clone from abort path\").(CVE-2024-26809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_conntrack_h323: Add protection for bmp length out of range\r\n\r\nUBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts\nthat are out of bounds for their data type.\r\n\r\nvmlinux get_bitmap(b=75) + 712\n\nvmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956\n\nvmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216\n\nvmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812\n\nvmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216\n\nvmlinux DecodeRasMessage() + 304\n\nvmlinux ras_help() + 684\n\nvmlinux nf_confirm() + 188\n\r\n\r\nDue to abnormal data in skb->data, the extension bitmap length\nexceeds 32 when decoding ras message then uses the length to make\na shift operation. It will change into negative after several loop.\nUBSAN load could detect a negative shift as an undefined behaviour\nand reports exception.\nSo we add the protection to avoid the length exceeding 32. Or else\nit will return out of range error and stop decoding.(CVE-2024-26851)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix kernel crash when 1588 is received on HIP08 devices\r\n\r\nThe HIP08 devices does not register the ptp devices, so the\nhdev->ptp is NULL, but the hardware can receive 1588 messages,\nand set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the\naccess of hdev->ptp->flags will cause a kernel crash:\r\n\r\n[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n...\n[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]\n[ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]\n[ 5889.279101] sp : ffff800012c3bc50\n[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040\n[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500\n[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000\n[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000\n[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080\n[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000\n[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000\n[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000\n[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df\n[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000\n[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d\n[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480\n[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000\n[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000\n[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080\n[ 5889.378857] Call trace:\n[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]\n[ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]\n[ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]\n[ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]\n[ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]\n[ 5889.411084] napi_poll+0xcc/0x264\n[ 5889.415329] net_rx_action+0xd4/0x21c\n[ 5889.419911] __do_softirq+0x130/0x358\n[ 5889.424484] irq_exit+0x134/0x154\n[ 5889.428700] __handle_domain_irq+0x88/0xf0\n[ 5889.433684] gic_handle_irq+0x78/0x2c0\n[ 5889.438319] el1_irq+0xb8/0x140\n[ 5889.442354] arch_cpu_idle+0x18/0x40\n[ 5889.446816] default_idle_call+0x5c/0x1c0\n[ 5889.451714] cpuidle_idle_call+0x174/0x1b0\n[ 5889.456692] do_idle+0xc8/0x160\n[ 5889.460717] cpu_startup_entry+0x30/0xfc\n[ 5889.465523] secondary_start_kernel+0x158/0x1ec\n[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)\n[ 5889.477950] SMP: stopping secondary CPUs\n[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95\n[ 5890.522951] Starting crashdump kernel...(CVE-2024-26881)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix kmemleak of rdev->serial\r\n\r\nIf kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be\nalloc not be freed, and kmemleak occurs.\r\n\r\nunreferenced object 0xffff88815a350000 (size 49152):\n comm \"mdadm\", pid 789, jiffies 4294716910\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc f773277a):\n [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0\n [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270\n [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f\n [<00000000f206d60a>] kvmalloc_node+0x74/0x150\n [<0000000034bf3363>] rdev_init_serial+0x67/0x170\n [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220\n [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630\n [<0000000073c28560>] md_add_new_disk+0x400/0x9f0\n [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10\n [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0\n [<0000000085086a11>] vfs_ioctl+0x22/0x60\n [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0\n [<00000000e54e675e>] do_syscall_64+0x71/0x150\n [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74(CVE-2024-26900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndo_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak\r\n\r\nsyzbot identified a kernel information leak vulnerability in\ndo_sys_name_to_handle() and issued the following report [1].\r\n\r\n[1]\n\"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n _copy_to_user+0xbc/0x100 lib/usercopy.c:40\n copy_to_user include/linux/uaccess.h:191 [inline]\n do_sys_name_to_handle fs/fhandle.c:73 [inline]\n __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]\n __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94\n __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94\n ...\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517\n __do_kmalloc_node mm/slab_common.c:1006 [inline]\n __kmalloc+0x121/0x3c0 mm/slab_common.c:1020\n kmalloc include/linux/slab.h:604 [inline]\n do_sys_name_to_handle fs/fhandle.c:39 [inline]\n __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]\n __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94\n __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94\n ...\r\n\r\nBytes 18-19 of 20 are uninitialized\nMemory access of size 20 starts at ffff888128a46380\nData copied to user address 0000000020000240\"\r\n\r\nPer Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to\nsolve the problem.(CVE-2024-26901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security\r\n\r\nDuring our fuzz testing of the connection and disconnection process at the\nRFCOMM layer, we discovered this bug. By comparing the packets from a\nnormal connection and disconnection process with the testcase that\ntriggered a KASAN report. We analyzed the cause of this bug as follows:\r\n\r\n1. In the packets captured during a normal connection, the host sends a\n`Read Encryption Key Size` type of `HCI_CMD` packet\n(Command Opcode: 0x1408) to the controller to inquire the length of\nencryption key.After receiving this packet, the controller immediately\nreplies with a Command Completepacket (Event Code: 0x0e) to return the\nEncryption Key Size.\r\n\r\n2. In our fuzz test case, the timing of the controller's response to this\npacket was delayed to an unexpected point: after the RFCOMM and L2CAP\nlayers had disconnected but before the HCI layer had disconnected.\r\n\r\n3. After receiving the Encryption Key Size Response at the time described\nin point 2, the host still called the rfcomm_check_security function.\nHowever, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`\nhad already been released, and when the function executed\n`return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,\nspecifically when accessing `conn->hcon`, a null-ptr-deref error occurred.\r\n\r\nTo fix this bug, check if `sk->sk_state` is BT_CLOSED before calling\nrfcomm_recv_frame in rfcomm_process_rx.(CVE-2024-26903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/mlx5: Fix fortify source warning while accessing Eth segment\r\n\r\n ------------[ cut here ]------------\n memcpy: detected field-spanning write (size 56) of single field \"eseg->inline_hdr.start\" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)\n WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy\n [last unloaded: mlx_compat(OE)]\n CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu\n Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\n RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7\n RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046\n RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8\n R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80\n FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \n ? show_regs+0x72/0x90\n ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n ? __warn+0x8d/0x160\n ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n ? report_bug+0x1bb/0x1d0\n ? handle_bug+0x46/0x90\n ? exc_invalid_op+0x19/0x80\n ? asm_exc_invalid_op+0x1b/0x20\n ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]\n ipoib_send+0x2ec/0x770 [ib_ipoib]\n ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]\n dev_hard_start_xmit+0x8e/0x1e0\n ? validate_xmit_skb_list+0x4d/0x80\n sch_direct_xmit+0x116/0x3a0\n __dev_xmit_skb+0x1fd/0x580\n __dev_queue_xmit+0x284/0x6b0\n ? _raw_spin_unlock_irq+0xe/0x50\n ? __flush_work.isra.0+0x20d/0x370\n ? push_pseudo_header+0x17/0x40 [ib_ipoib]\n neigh_connected_output+0xcd/0x110\n ip_finish_output2+0x179/0x480\n ? __smp_call_single_queue+0x61/0xa0\n __ip_finish_output+0xc3/0x190\n ip_finish_output+0x2e/0xf0\n ip_output+0x78/0x110\n ? __pfx_ip_finish_output+0x10/0x10\n ip_local_out+0x64/0x70\n __ip_queue_xmit+0x18a/0x460\n ip_queue_xmit+0x15/0x30\n __tcp_transmit_skb+0x914/0x9c0\n tcp_write_xmit+0x334/0x8d0\n tcp_push_one+0x3c/0x60\n tcp_sendmsg_locked+0x2e1/0xac0\n tcp_sendmsg+0x2d/0x50\n inet_sendmsg+0x43/0x90\n sock_sendmsg+0x68/0x80\n sock_write_iter+0x93/0x100\n vfs_write+0x326/0x3c0\n ksys_write+0xbd/0xf0\n ? do_syscall_64+0x69/0x90\n __x64_sys_write+0x19/0x30\n do_syscall_\n---truncated---(CVE-2024-26907)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-26908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Reset queue_priority_hint on parking\r\n\r\nOriginally, with strict in order execution, we could complete execution\nonly when the queue was empty. Preempt-to-busy allows replacement of an\nactive request that may complete before the preemption is processed by\nHW. If that happens, the request is retired from the queue, but the\nqueue_priority_hint remains set, preventing direct submission until\nafter the next CS interrupt is processed.\r\n\r\nThis preempt-to-busy race can be triggered by the heartbeat, which will\nalso act as the power-management barrier and upon completion allow us to\nidle the HW. We may process the completion of the heartbeat, and begin\nparking the engine before the CS event that restores the\nqueue_priority_hint, causing us to fail the assertion that it is MIN.\r\n\r\n<3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))\n<0>[ 166.210781] Dumping ftrace buffer:\n<0>[ 166.210795] ---------------------------------\n...\n<0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }\n<0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646\n<0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0\n<0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659\n<0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40\n<0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }\n<0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2\n<0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin\n<0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2\n<0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin\n<0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660\n<0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }\n<0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked\n<0>[ 167.303534] -0 5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040\n<0>[ 167.303583] kworker/-89 11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }\n<0>[ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }\n<0>[ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))\n<0>[ 167.303811] ---------------------------------\n<4>[ 167.304722] ------------[ cut here ]------------\n<2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!\n<4>[ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n<4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1\n<4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022\n<4>[ 167.304738] Workqueue: i915-unordered retire_work_handler [i915]\n<4>[ 16\n---truncated---(CVE-2024-26937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: openvswitch: Fix Use-After-Free in ovs_ct_exit\r\n\r\nSince kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal\nof ovs_ct_limit_exit, is not part of the RCU read critical section, it\nis possible that the RCU grace period will pass during the traversal and\nthe key will be free.\r\n\r\nTo prevent this, it should be changed to hlist_for_each_entry_safe.(CVE-2024-27395)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: gtp: Fix Use-After-Free in gtp_dellink\r\n\r\nSince call_rcu, which is called in the hlist_for_each_entry_rcu traversal\nof gtp_dellink, is not part of the RCU read critical section, it\nis possible that the RCU grace period will pass during the traversal and\nthe key will be free.\r\n\r\nTo prevent this, it should be changed to hlist_for_each_entry_safe.(CVE-2024-27396)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: Fix use-after-free bugs caused by sco_sock_timeout\r\n\r\nWhen the sco connection is established and then, the sco socket\nis releasing, timeout_work will be scheduled to judge whether\nthe sco disconnection is timeout. The sock will be deallocated\nlater, but it is dereferenced again in sco_sock_timeout. As a\nresult, the use-after-free bugs will happen. The root cause is\nshown below:\r\n\r\n Cleanup Thread | Worker Thread\nsco_sock_release |\n sco_sock_close |\n __sco_sock_close |\n sco_sock_set_timer |\n schedule_delayed_work |\n sco_sock_kill | (wait a time)\n sock_put(sk) //FREE | sco_sock_timeout\n | sock_hold(sk) //USE\r\n\r\nThe KASAN report triggered by POC is shown below:\r\n\r\n[ 95.890016] ==================================================================\n[ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0\n[ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7\n...\n[ 95.890755] Workqueue: events sco_sock_timeout\n[ 95.890755] Call Trace:\n[ 95.890755] \n[ 95.890755] dump_stack_lvl+0x45/0x110\n[ 95.890755] print_address_description+0x78/0x390\n[ 95.890755] print_report+0x11b/0x250\n[ 95.890755] ? __virt_addr_valid+0xbe/0xf0\n[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0\n[ 95.890755] kasan_report+0x139/0x170\n[ 95.890755] ? update_load_avg+0xe5/0x9f0\n[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0\n[ 95.890755] kasan_check_range+0x2c3/0x2e0\n[ 95.890755] sco_sock_timeout+0x5e/0x1c0\n[ 95.890755] process_one_work+0x561/0xc50\n[ 95.890755] worker_thread+0xab2/0x13c0\n[ 95.890755] ? pr_cont_work+0x490/0x490\n[ 95.890755] kthread+0x279/0x300\n[ 95.890755] ? pr_cont_work+0x490/0x490\n[ 95.890755] ? kthread_blkcg+0xa0/0xa0\n[ 95.890755] ret_from_fork+0x34/0x60\n[ 95.890755] ? kthread_blkcg+0xa0/0xa0\n[ 95.890755] ret_from_fork_asm+0x11/0x20\n[ 95.890755] \n[ 95.890755]\n[ 95.890755] Allocated by task 506:\n[ 95.890755] kasan_save_track+0x3f/0x70\n[ 95.890755] __kasan_kmalloc+0x86/0x90\n[ 95.890755] __kmalloc+0x17f/0x360\n[ 95.890755] sk_prot_alloc+0xe1/0x1a0\n[ 95.890755] sk_alloc+0x31/0x4e0\n[ 95.890755] bt_sock_alloc+0x2b/0x2a0\n[ 95.890755] sco_sock_create+0xad/0x320\n[ 95.890755] bt_sock_create+0x145/0x320\n[ 95.890755] __sock_create+0x2e1/0x650\n[ 95.890755] __sys_socket+0xd0/0x280\n[ 95.890755] __x64_sys_socket+0x75/0x80\n[ 95.890755] do_syscall_64+0xc4/0x1b0\n[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f\n[ 95.890755]\n[ 95.890755] Freed by task 506:\n[ 95.890755] kasan_save_track+0x3f/0x70\n[ 95.890755] kasan_save_free_info+0x40/0x50\n[ 95.890755] poison_slab_object+0x118/0x180\n[ 95.890755] __kasan_slab_free+0x12/0x30\n[ 95.890755] kfree+0xb2/0x240\n[ 95.890755] __sk_destruct+0x317/0x410\n[ 95.890755] sco_sock_release+0x232/0x280\n[ 95.890755] sock_close+0xb2/0x210\n[ 95.890755] __fput+0x37f/0x770\n[ 95.890755] task_work_run+0x1ae/0x210\n[ 95.890755] get_signal+0xe17/0xf70\n[ 95.890755] arch_do_signal_or_restart+0x3f/0x520\n[ 95.890755] syscall_exit_to_user_mode+0x55/0x120\n[ 95.890755] do_syscall_64+0xd1/0x1b0\n[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f\n[ 95.890755]\n[ 95.890755] The buggy address belongs to the object at ffff88800c388000\n[ 95.890755] which belongs to the cache kmalloc-1k of size 1024\n[ 95.890755] The buggy address is located 128 bytes inside of\n[ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)\n[ 95.890755]\n[ 95.890755] The buggy address belongs to the physical page:\n[ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388\n[ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n[ 95.890755] ano\n---truncated---(CVE-2024-27398)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpumap: Zero-initialise xdp_rxq_info struct before running XDP program\r\n\r\nWhen running an XDP program that is attached to a cpumap entry, we don't\ninitialise the xdp_rxq_info data structure being used in the xdp_buff\nthat backs the XDP program invocation. Tobias noticed that this leads to\nrandom values being returned as the xdp_md->rx_queue_index value for XDP\nprograms running in a cpumap.\r\n\r\nThis means we're basically returning the contents of the uninitialised\nmemory, which is bad. Fix this by zero-initialising the rxq data\nstructure before running the XDP program.(CVE-2024-27431)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix information leak in btrfs_ioctl_logical_to_ino()\r\n\r\nSyzbot reported the following information leak for in\nbtrfs_ioctl_logical_to_ino():\r\n\r\n BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n copy_to_user include/linux/uaccess.h:191 [inline]\n btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499\n btrfs_ioctl+0x714/0x1260\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\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\r\n\r\n Uninit was created at:\n __kmalloc_large_node+0x231/0x370 mm/slub.c:3921\n __do_kmalloc_node mm/slub.c:3954 [inline]\n __kmalloc_node+0xb07/0x1060 mm/slub.c:3973\n kmalloc_node include/linux/slab.h:648 [inline]\n kvmalloc_node+0xc0/0x2d0 mm/util.c:634\n kvmalloc include/linux/slab.h:766 [inline]\n init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779\n btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480\n btrfs_ioctl+0x714/0x1260\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\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\r\n\r\n Bytes 40-65535 of 65536 are uninitialized\n Memory access of size 65536 starts at ffff888045a40000\r\n\r\nThis happens, because we're copying a 'struct btrfs_data_container' back\nto user-space. This btrfs_data_container is allocated in\n'init_data_container()' via kvmalloc(), which does not zero-fill the\nmemory.\r\n\r\nFix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npmdomain: ti: Add a null pointer check to the omap_prm_domain_init\r\n\r\ndevm_kasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.(CVE-2024-35943)", + "cves": [ + { + "id": "CVE-2024-35943", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35943", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1040": { + "id": "openEuler-SA-2023-1040", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1040", + "title": "An update for kernel is now available for openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\nA flaw incorrect access control in the Linux kernel USB core subsystem was found in the way user attaches usb device. A local user could use this flaw to crash the system.(CVE-2022-4662)", + "cves": [ + { + "id": "CVE-2022-4662", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4662", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2022-1717": { + "id": "openEuler-SA-2022-1717", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1717", + "title": "An update for vim is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3 and openEuler-22.03-LTS", + "severity": "High", + "description": "Vim is an advanced text editor that seeks to provide the power of the de-facto Unix editor 'Vi', with a more complete feature set. Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems.\r\n\r\nSecurity Fix(es):\r\n\r\nOut-of-bounds Read in GitHub repository vim/vim prior to 8.2.(CVE-2022-1851)\r\n\r\nUse After Free in GitHub repository vim/vim prior to 8.2.(CVE-2022-1898)\r\n\r\nHeap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2.(CVE-2022-1942)\r\n\r\nOut-of-bounds Write in GitHub repository vim/vim prior to 8.2.(CVE-2022-1897)\r\n\r\nUse After Free in GitHub repository vim/vim prior to 8.2.(CVE-2022-1968)\n\nUncontrolled Recursion in GitHub repository vim/vim prior to 8.2.4975.(CVE-2022-1771)", + "cves": [ + { + "id": "CVE-2022-1771", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1771", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-2087": { + "id": "openEuler-SA-2022-2087", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-2087", + "title": "An update for festival is now available for openEuler-22.03-LTS", + "severity": "High", + "description": "Festival offers a general framework for building speech synthesis systems as well as including examples of various modules. As a whole it offers full text to speech through a number APIs: from shell level, though a Scheme command interpreter, as a C++ library, from Java, and an Emacs interface.\r\n\r\nSecurity Fix(es):\r\n\r\nfestival_server in Centre for Speech Technology Research (CSTR) Festival, probably 2.0.95-beta and earlier, places a zero-length directory name in the LD_LIBRARY_PATH, which allows local users to gain privileges via a Trojan horse shared library in the current working directory.(CVE-2010-3996)", + "cves": [ + { + "id": "CVE-2010-3996", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-3996", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-1975": { + "id": "openEuler-SA-2022-1975", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1975", + "title": "An update for vim is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3 and openEuler-22.03-LTS", + "severity": "High", + "description": "Vim is an advanced text editor that seeks to provide the power of the de-facto Unix editor 'Vi', with a more complete feature set. Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems.\r\n\r\nSecurity Fix(es):\r\n\r\nHeap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.0483.(CVE-2022-3234)\r\n\r\nUse After Free in GitHub repository vim/vim prior to 9.0.0490.(CVE-2022-3235)\r\n\r\nUse After Free in GitHub repository vim/vim prior to 9.0.0530.(CVE-2022-3256)", + "cves": [ + { + "id": "CVE-2022-3256", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3256", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-2085": { + "id": "openEuler-SA-2022-2085", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-2085", + "title": "An update for firefox is now available for openEuler-22.03-LTS", + "severity": "Critical", + "description": "Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability. %if 0 %global moz_debug_prefix /lib/debug %global moz_debug_dir /lib/debug/ %global uname_m %(uname -m) %global symbols_file_name -.en-US.-%(uname.crashreporter-symbols.zip %global symbols_file_path /lib/debug//-.en-US.-%(uname.crashreporter-symbols.zip %global _find_debuginfo_opts -p /lib/debug//-.en-US.-%(uname.crashreporter-symbols.zip -o debugcrashreporter.list %global crashreporter_pkg_name mozilla-crashreporter--debuginfo\r\n\r\nSecurity Fix(es):\r\n\r\nxmltok_impl.c in Expat (aka libexpat) before 2.4.5 lacks certain validation of encoding, such as checks for whether a UTF-8 character is valid in a certain context.(CVE-2022-25235)\r\n\r\nxmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to insert namespace-separator characters into namespace URIs.(CVE-2022-25236)\r\n\r\nIn Expat (aka libexpat) before 2.4.5, there is an integer overflow in storeRawNames.(CVE-2022-25315)", + "cves": [ + { + "id": "CVE-2022-25315", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25315", + "severity": "Critical" + } + ] + }, + "openEuler-SA-2022-2086": { + "id": "openEuler-SA-2022-2086", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-2086", + "title": "An update for python-pillow is now available for openEuler-22.03-LTS", + "severity": "Medium", + "description": "\r\n\r\nSecurity Fix(es):\r\n\r\nPillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.(CVE-2022-24303)", + "cves": [ + { + "id": "CVE-2022-24303", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24303", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2024-1199": { + "id": "openEuler-SA-2024-1199", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1199", + "title": "An update for indent is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS,openEuler-22.03-LTS-SP1,openEuler-22.03-LTS-SP2 and openEuler-22.03-LTS-SP3", + "severity": "Medium", + "description": "The indent program can be used to make code easier to read. It can also convert from one style of writing C to another. indent understands a substantial amount about the syntax of C, but it also attempts to cope with incomplete and misformed syntax.\r\n\r\nSecurity Fix(es):\r\n\r\nA flaw was found in indent, a program for formatting C code. This issue may allow an attacker to trick a user into processing a specially crafted file to trigger a heap-based buffer overflow, causing the application to crash.(CVE-2024-0911)", + "cves": [ + { + "id": "CVE-2024-0911", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0911", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1195": { + "id": "openEuler-SA-2023-1195", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1195", + "title": "An update for curl is now available for openEuler-20.03-LTS-SP3", + "severity": "Medium", + "description": "cURL is a computer software project providing a library (libcurl) and command-line tool (curl) for transferring data using various protocols.\r\n\r\nSecurity Fix(es):\r\n\r\nlibcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, several FTP settings were left out from the configuration match checks, making them match too easily. The settings in questions are `CURLOPT_FTP_ACCOUNT`, `CURLOPT_FTP_ALTERNATIVE_TO_USER`, `CURLOPT_FTP_SSL_CCC` and `CURLOPT_USE_SSL` level.(CVE-2023-27535)\r\n\r\nlibcurl would reuse a previously created connection even when an SSH related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, two SSH settings were left out from the configuration match checks, making them match too easily.(CVE-2023-27538)\r\n\r\nlibcurl would reuse a previously created connection even when the GSS delegation (`CURLOPT_GSSAPI_DELEGATION`) option had been changed that could have changed the user's permissions in a second transfer. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, this GSS delegation setting was left out from the configuration match checks, making them match too easily, affecting krb5/kerberos/negotiate/GSSAPI transfers.(CVE-2023-27536)\r\n\r\ncurl supports communicating using the TELNET protocol and as a part of this it offers users to pass on user name and \"telnet options\" for the server\nnegotiation. Due to lack of proper input scrubbing and without it being the documented functionality, curl would pass on user name and telnet options to the server as provided. This could allow users to pass in carefully crafted content that pass on content or do option negotiation without the application intending to do so. In particular if an application for example allows users to provide the data or parts of the data.(CVE-2023-27533)\r\n\r\ncurl supports SFTP transfers. curl's SFTP implementation offers a special feature in the path component of URLs: a tilde (`~`) character as the first\npath element in the path to denotes a path relative to the user's home directory. This is supported because of wording in the [once proposed\nto-become RFC draft](https://datatracker.ietf.org/doc/html/draft-ietf-secsh-scp-sftp-ssh-uri-04) that was to dictate how SFTP URLs work. Due to a bug, the handling of the tilde in SFTP path did however not only replace it when it is used stand-alone as the first path element but also wrongly when used as a mere prefix in the first element. Using a path like `/~2/foo` when accessing a server using the user `dan` (with home directory `/home/dan`) would then quite suprisingly access the file `/home/dan2/foo`. This can be taken advantage of to circumvent filtering or worse.(CVE-2023-27534)", + "cves": [ + { + "id": "CVE-2023-27534", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27534", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2022-1756": { + "id": "openEuler-SA-2022-1756", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1756", + "title": "An update for libproxy is now available for openEuler-20.03-LTS-SP1 and openEuler-20.03-LTS-SP3", + "severity": "High", + "description": "libproxy offers the following features:* extremely small core footprint (< 35k).* no external dependencies within libproxy core.(libproxy plugins may have dependencies).* only 3 functions in the stable external API.* dynamic adjustment to changing network topology.* a standard way of dealing with proxy settings across all scenarios.\r\n\r\nSecurity Fix(es):\r\n\r\nurl::recvline in url.cpp in libproxy 0.4.x through 0.4.15 allows a remote HTTP server to trigger uncontrolled recursion via a response composed of an infinite stream that lacks a newline character. This leads to stack exhaustion.(CVE-2020-25219)", + "cves": [ + { + "id": "CVE-2020-25219", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25219", + "severity": "High" + } + ] + }, + "openEuler-SA-2024-1493": { + "id": "openEuler-SA-2024-1493", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1493", + "title": "An update for atril is now available for openEuler-22.03-LTS", + "severity": "High", + "description": "Mate-document-viewer is simple document viewer. It can display and print Portable Document Format (PDF), PostScript (PS), Encapsulated PostScript (EPS), DVI, DJVU, epub and XPS files. When supported by the document format, mate-document-viewer allows searching for text, copying text to the clipboard, hypertext navigation, table-of-contents bookmarks and editing of forms.\r\n\r\nSecurity Fix(es):\r\n\r\nAtril is a simple multi-page document viewer. Atril is vulnerable to a critical Command Injection Vulnerability. This vulnerability gives the attacker immediate access to the target system when the target user opens a crafted document or clicks on a crafted link/URL using a maliciously crafted CBT document which is a TAR archive. A patch is available at commit ce41df6.\n(CVE-2023-51698)", + "cves": [ + { + "id": "CVE-2023-51698", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51698", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1313": { + "id": "openEuler-SA-2023-1313", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1313", + "title": "An update for c-ares is now available for openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "This is c-ares, an asynchronous resolver library. It is intended for applications which need to perform DNS queries without blocking, or need to perform multiple\r\n\r\nSecurity Fix(es):\r\n\r\nc-ares is an asynchronous resolver library. c-ares is vulnerable to denial of service. If a target resolver sends a query, the attacker forges a malformed UDP packet with a length of 0 and returns them to the target resolver. The target resolver erroneously interprets the 0 length as a graceful shutdown of the connection. This issue has been patched in version 1.19.1.(CVE-2023-32067)\r\n\r\nc-ares is an asynchronous resolver library. When /dev/urandom or RtlGenRandom() are unavailable, c-ares uses rand() to generate random numbers used for DNS query ids. This is not a CSPRNG, and it is also not seeded by srand() so will generate predictable output. Input from the random number generator is fed into a non-compilant RC4 implementation and may not be as strong as the original RC4 implementation. No attempt is made to look for modern OS-provided CSPRNGs like arc4random() that is widely available. This issue has been fixed in version 1.19.1.(CVE-2023-31147)", + "cves": [ + { + "id": "CVE-2023-32067", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32067", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1599": { + "id": "openEuler-SA-2023-1599", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1599", + "title": "An update for libtiff is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS,openEuler-22.03-LTS-SP1 and openEuler-22.03-LTS-SP2", + "severity": "Medium", + "description": "This provides support for the Tag Image File Format (TIFF), a widely used format for storing image data. The latest version of the TIFF specification is available on-line in several different formats.And contains command-line programs for manipulating TIFF format image files using the libtiff library.\r\n\r\nSecurity Fix(es):\r\n\r\nAn issue was discovered in function TIFFReadDirectory libtiff before 4.4.0 allows attackers to cause a denial of service via crafted TIFF file.(CVE-2022-40090)", + "cves": [ + { + "id": "CVE-2022-40090", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40090", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1839": { + "id": "openEuler-SA-2023-1839", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1839", + "title": "An update for openjdk-1.8.0 is now available for openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "The OpenJDK runtime environment 8.\r\n\r\nSecurity Fix(es):\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: CORBA). Supported versions that are affected are Oracle Java SE: 8u381, 8u381-perf; Oracle GraalVM Enterprise Edition: 20.3.11 and 21.3.7. Easily exploitable vulnerability allows unauthenticated attacker with network access via CORBA to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-22067)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u381, 8u381-perf, 11.0.20, 17.0.8, 21; Oracle GraalVM for JDK: 17.0.8, 21; Oracle GraalVM Enterprise Edition: 20.3.11, 21.3.7 and 22.3.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2023-22081)", + "cves": [ + { + "id": "CVE-2023-22081", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22081", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2021-1153": { + "id": "openEuler-SA-2021-1153", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2021-1153", + "title": "An update for binutils is now available for openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "\r\n\r\nSecurity Fix(es):\r\n\r\nThere is an open race window when writing output in the following utilities in GNU binutils version 2.35 and earlier:ar, objcopy, strip, ranlib. When these utilities are run as a privileged user (presumably as part of a script updating binaries across different users), an unprivileged user can trick these utilities into getting ownership of arbitrary files through a symlink.(CVE-2021-20197)", + "cves": [ + { + "id": "CVE-2021-20197", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20197", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2024-1290": { + "id": "openEuler-SA-2024-1290", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1290", + "title": "An update for iSulad is now available for openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "This is a umbrella project for gRPC-services based Lightweight Container Runtime Daemon, written by C.\r\n\r\nSecurity Fix(es):\r\n\r\n在isulad服务初始化阶段,会进行临时文件的正确性检查,如果检查不通过则重新创建文件,在检查与创建之间,存在一个条件竞争问题,攻击者可以通过利用该漏洞进行提权。(CVE-2021-33632)", + "cves": [ + { + "id": "CVE-2021-33632", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33632", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1354": { + "id": "openEuler-SA-2023-1354", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1354", + "title": "An update for openssl is now available for openEuler-20.03-LTS-SP1", + "severity": "High", + "description": "OpenSSL is a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols.\n\nSecurity Fix(es):\n\nIssue summary: Processing some specially crafted ASN.1 object identifiers or\ndata containing them may be very slow.\n\nImpact summary: Applications that use OBJ_obj2txt() directly, or use any of\nthe OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message\nsize limit may experience notable to very long delays when processing those\nmessages, which may lead to a Denial of Service.\n\nAn OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers -\nmost of which have no size limit. OBJ_obj2txt() may be used to translate\nan ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL\ntype ASN1_OBJECT) to its canonical numeric text form, which are the\nsub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by\nperiods.\n\nWhen one of the sub-identifiers in the OBJECT IDENTIFIER is very large\n(these are sizes that are seen as absurdly large, taking up tens or hundreds\nof KiBs), the translation to a decimal number in text may take a very long\ntime. The time complexity is O(n^2) with 'n' being the size of the\nsub-identifiers in bytes (*).\n\nWith OpenSSL 3.0, support to fetch cryptographic algorithms using names /\nidentifiers in string form was introduced. This includes using OBJECT\nIDENTIFIERs in canonical numeric text form as identifiers for fetching\nalgorithms.\n\nSuch OBJECT IDENTIFIERs may be received through the ASN.1 structure\nAlgorithmIdentifier, which is commonly used in multiple protocols to specify\nwhat cryptographic algorithm should be used to sign or verify, encrypt or\ndecrypt, or digest passed data.\n\nApplications that call OBJ_obj2txt() directly with untrusted data are\naffected, with any version of OpenSSL. If the use is for the mere purpose\nof display, the severity is considered low.\n\nIn OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME,\nCMS, CMP/CRMF or TS. It also impacts anything that processes X.509\ncertificates, including simple things like verifying its signature.\n\nThe impact on TLS is relatively low, because all versions of OpenSSL have a\n100KiB limit on the peer's certificate chain. Additionally, this only\nimpacts clients, or servers that have explicitly enabled client\nauthentication.\n\nIn OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects,\nsuch as X.509 certificates. This is assumed to not happen in such a way\nthat it would cause a Denial of Service, so these versions are considered\nnot affected by this issue in such a way that it would be cause for concern,\nand the severity is therefore considered low.(CVE-2023-2650)", + "cves": [ + { + "id": "CVE-2023-2650", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2650", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1551": { + "id": "openEuler-SA-2023-1551", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1551", + "title": "An update for nodejs is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS,openEuler-22.03-LTS-SP1 and openEuler-22.03-LTS-SP2", + "severity": "Critical", + "description": "Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.\r\n\r\nSecurity Fix(es):\r\n\r\nThis affects versions of the package http-cache-semantics before 4.1.1. The issue can be exploited via malicious request header values sent to a server, when that server reads the cache policy from the request using this library.\r\n\r\n(CVE-2022-25881)\r\n\r\nA OS Command Injection vulnerability exists in Node.js versions <14.20.0, <16.20.0, <18.5.0 due to an insufficient IsAllowedHost check that can easily be bypassed because IsIPAddress does not properly check if an IP address is invalid before making DBS requests allowing rebinding attacks.(CVE-2022-32212)\r\n\r\nThe llhttp parser th_buf.gnu_longlink after allocating memory, which may cause a memory leak.(CVE-2021-33645)\r\n\r\nThe th_read() function doesn’t free a variable t->th_buf.gnu_longname after allocating memory, which may cause a memory leak.(CVE-2021-33646)", + "cves": [ + { + "id": "CVE-2021-33646", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33646", + "severity": "Low" + } + ] + }, + "openEuler-SA-2024-1682": { + "id": "openEuler-SA-2024-1682", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1682", + "title": "An update for kernel is now available for openEuler-22.03-LTS-SP3", + "severity": "High", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume\r\n\r\nIn current code, when a PCI error state pci_channel_io_normal is detectd,\nit will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI\ndriver will continue the execution of PCI resume callback report_resume by\npci_walk_bridge, and the callback will go into amdgpu_pci_resume\nfinally, where write lock is releasd unconditionally without acquiring\nsuch lock first. In this case, a deadlock will happen when other threads\nstart to acquire the read lock.\r\n\r\nTo fix this, add a member in amdgpu_device strucutre to cache\npci_channel_state, and only continue the execution in amdgpu_pci_resume\nwhen it's pci_channel_io_frozen.(CVE-2021-47421)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nptp: Fix possible memory leak in ptp_clock_register()\r\n\r\nI got memory leak as follows when doing fault injection test:\r\n\r\nunreferenced object 0xffff88800906c618 (size 8):\n comm \"i2c-idt82p33931\", pid 4421, jiffies 4294948083 (age 13.188s)\n hex dump (first 8 bytes):\n 70 74 70 30 00 00 00 00 ptp0....\n backtrace:\n [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0\n [<0000000079f6e2ff>] kvasprintf+0xb5/0x150\n [<0000000026aae54f>] kvasprintf_const+0x60/0x190\n [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150\n [<000000004e35abdd>] dev_set_name+0xc0/0x100\n [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp]\n [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]\r\n\r\nWhen posix_clock_register() returns an error, the name allocated\nin dev_set_name() will be leaked, the put_device() should be used\nto give up the device reference, then the name will be freed in\nkobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: enetc: deny offload of tc-based TSN features on VF interfaces\r\n\r\nTSN features on the ENETC (taprio, cbs, gate, police) are configured\nthrough a mix of command BD ring messages and port registers:\nenetc_port_rd(), enetc_port_wr().\r\n\r\nPort registers are a region of the ENETC memory map which are only\naccessible from the PCIe Physical Function. They are not accessible from\nthe Virtual Functions.\r\n\r\nMoreover, attempting to access these registers crashes the kernel:\r\n\r\n$ echo 1 > /sys/bus/pci/devices/0000\\:00\\:00.0/sriov_numvfs\npci 0000:00:01.0: [1957:ef00] type 00 class 0x020001\nfsl_enetc_vf 0000:00:01.0: Adding to iommu group 15\nfsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002)\nfsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0\n$ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \\\n\tqueues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \\\n\tsched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2\nUnable to handle kernel paging request at virtual address ffff800009551a08\nInternal error: Oops: 96000007 [#1] PREEMPT SMP\npc : enetc_setup_tc_taprio+0x170/0x47c\nlr : enetc_setup_tc_taprio+0x16c/0x47c\nCall trace:\n enetc_setup_tc_taprio+0x170/0x47c\n enetc_setup_tc+0x38/0x2dc\n taprio_change+0x43c/0x970\n taprio_init+0x188/0x1e0\n qdisc_create+0x114/0x470\n tc_modify_qdisc+0x1fc/0x6c0\n rtnetlink_rcv_msg+0x12c/0x390\r\n\r\nSplit enetc_setup_tc() into separate functions for the PF and for the\nVF drivers. Also remove enetc_qos.o from being included into\nenetc-vf.ko, since it serves absolutely no purpose there.(CVE-2022-48645)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/tegra: dsi: Add missing check for of_find_device_by_node\r\n\r\nAdd check for the return value of of_find_device_by_node() and return\nthe error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNTB: fix possible name leak in ntb_register_device()\r\n\r\nIf device_register() fails in ntb_register_device(), the device name\nallocated by dev_set_name() should be freed. As per the comment in\ndevice_register(), callers should use put_device() to give up the\nreference in the error path. So fix this by calling put_device() in the\nerror path so that the name can be freed in kobject_cleanup().\r\n\r\nAs a result of this, put_device() in the error path of\nntb_register_device() is removed and the actual error is returned.\r\n\r\n[mani: reworded commit message](CVE-2023-52652)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix a memleak in gss_import_v2_context\r\n\r\nThe ctx->mech_used.data allocated by kmemdup is not freed in neither\ngss_import_v2_context nor it only caller gss_krb5_import_sec_context,\nwhich frees ctx on error.\r\n\r\nThus, this patch reform the last call of gss_import_v2_context to the\ngss_krb5_import_ctx_v2, preventing the memleak while keepping the return\nformation.(CVE-2023-52653)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: drop any code related to SCM_RIGHTS\r\n\r\nThis is dead code after we dropped support for passing io_uring fds\nover SCM_RIGHTS, get rid of it.(CVE-2023-52656)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: atlantic: eliminate double free in error handling logic\r\n\r\nDriver has a logic leak in ring data allocation/free,\nwhere aq_ring_free could be called multiple times on same ring,\nif system is under stress and got memory allocation error.\r\n\r\nRing pointer was used as an indicator of failure, but this is\nnot correct since only ring data is allocated/deallocated.\nRing itself is an array member.\r\n\r\nChanging ring allocation functions to return error code directly.\nThis simplifies error handling and eliminates aq_ring_free\non higher layer.(CVE-2023-52664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()\r\n\r\nEnsure the value passed to scarlett2_mixer_ctl_put() is between 0 and\nSCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside\nscarlett2_mixer_values[].(CVE-2023-52674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: LPIT: Avoid u32 multiplication overflow\r\n\r\nIn lpit_update_residency() there is a possibility of overflow\nin multiplication, if tsc_khz is large enough (> UINT_MAX/1000).\r\n\r\nChange multiplication to mul_u32_u32().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncalipso: fix memory leak in netlbl_calipso_add_pass()\r\n\r\nIf IPv6 support is disabled at boot (ipv6.disable=1),\nthe calipso_init() -> netlbl_calipso_ops_register() function isn't called,\nand the netlbl_calipso_ops_get() function always returns NULL.\nIn this case, the netlbl_calipso_add_pass() function allocates memory\nfor the doi_def variable but doesn't free it with the calipso_doi_free().\r\n\r\nBUG: memory leak\nunreferenced object 0xffff888011d68180 (size 64):\n comm \"syz-executor.1\", pid 10746, jiffies 4295410986 (age 17.928s)\n hex dump (first 32 bytes):\n 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<...>] kmalloc include/linux/slab.h:552 [inline]\n [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]\n [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111\n [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739\n [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800\n [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515\n [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811\n [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339\n [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934\n [<...>] sock_sendmsg_nosec net/socket.c:651 [inline]\n [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671\n [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342\n [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396\n [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429\n [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46\n [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6\r\n\r\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller\r\n\r\n[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add validity check for db_maxag and db_agpref\r\n\r\nBoth db_maxag and db_agpref are used as the index of the\ndb_agfree array, but there is currently no validity check for\ndb_maxag and db_agpref, which can lead to errors.\r\n\r\nThe following is related bug reported by Syzbot:\r\n\r\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20\nindex 7936 is out of range for type 'atomic_t[128]'\r\n\r\nAdd checking that the values of db_maxag and db_agpref are valid\nindexes for the db_agfree array.(CVE-2023-52804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in diAlloc\r\n\r\nCurrently there is not check against the agno of the iag while\nallocating new inodes to avoid fragmentation problem. Added the check\nwhich is required.(CVE-2023-52805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\r\n\r\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed.(CVE-2023-52809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL\r\n\r\nIn certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:\r\n\r\n1. Navigate to the directory: /sys/kernel/debug/dri/0\n2. Execute command: cat amdgpu_regs_smc\n3. Exception Log::\n[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[4005007.702562] #PF: supervisor instruction fetch in kernel mode\n[4005007.702567] #PF: error_code(0x0010) - not-present page\n[4005007.702570] PGD 0 P4D 0\n[4005007.702576] Oops: 0010 [#1] SMP NOPTI\n[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u\n[4005007.702590] RIP: 0010:0x0\n[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.\n[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206\n[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68\n[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000\n[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980\n[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000\n[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000\n[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000\n[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0\n[4005007.702633] Call Trace:\n[4005007.702636] \n[4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]\n[4005007.703002] full_proxy_read+0x5c/0x80\n[4005007.703011] vfs_read+0x9f/0x1a0\n[4005007.703019] ksys_read+0x67/0xe0\n[4005007.703023] __x64_sys_read+0x19/0x20\n[4005007.703028] do_syscall_64+0x5c/0xc0\n[4005007.703034] ? do_user_addr_fault+0x1e3/0x670\n[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0\n[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20\n[4005007.703052] ? irqentry_exit+0x19/0x30\n[4005007.703057] ? exc_page_fault+0x89/0x160\n[4005007.703062] ? asm_exc_page_fault+0x8/0x30\n[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[4005007.703075] RIP: 0033:0x7f5e07672992\n[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24\n[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992\n[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003\n[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010\n[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000\n[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000\n[4005007.703105] \n[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca\n[4005007.703184] CR2: 0000000000000000\n[4005007.703188] ---[ en\n---truncated---(CVE-2023-52817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for SMU7\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/core: Bail out early if the request AUX area is out of bound\r\n\r\nWhen perf-record with a large AUX area, e.g 4GB, it fails with:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)\r\n\r\nand it reveals a WARNING with __alloc_pages():\r\n\r\n\t------------[ cut here ]------------\n\tWARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248\n\tCall trace:\n\t __alloc_pages+0x1ec/0x248\n\t __kmalloc_large_node+0xc0/0x1f8\n\t __kmalloc_node+0x134/0x1e8\n\t rb_alloc_aux+0xe0/0x298\n\t perf_mmap+0x440/0x660\n\t mmap_region+0x308/0x8a8\n\t do_mmap+0x3c0/0x528\n\t vm_mmap_pgoff+0xf4/0x1b8\n\t ksys_mmap_pgoff+0x18c/0x218\n\t __arm64_sys_mmap+0x38/0x58\n\t invoke_syscall+0x50/0x128\n\t el0_svc_common.constprop.0+0x58/0x188\n\t do_el0_svc+0x34/0x50\n\t el0_svc+0x34/0x108\n\t el0t_64_sync_handler+0xb8/0xc0\n\t el0t_64_sync+0x1a4/0x1a8\r\n\r\n'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to\nmaintains AUX trace pages. The allocated page for this array is physically\ncontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the\nsize of pointer array crosses the limitation set by MAX_ORDER, it reveals a\nWARNING.\r\n\r\nSo bail out early with -ENOMEM if the request AUX area is out of bound,\ne.g.:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: synaptics-rmi4 - fix use after free in rmi_unregister_function()\r\n\r\nThe put_device() calls rmi_release_function() which frees \"fn\" so the\ndereference on the next line \"fn->num_of_irqs\" is a use after free.\nMove the put_device() to the end to fix this.(CVE-2023-52840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vidtv: psi: Add check for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.(CVE-2023-52844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Change nla_policy for bearer-related names to NLA_NUL_STRING\r\n\r\nsyzbot reported the following uninit-value access issue [1]:\r\n\r\n=====================================================\nBUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]\nBUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756\n strlen lib/string.c:418 [inline]\n strstr+0xb8/0x2f0 lib/string.c:756\n tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595\n genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]\n genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066\n netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545\n genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075\n netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]\n netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559\n __alloc_skb+0x318/0x740 net/core/skbuff.c:650\n alloc_skb include/linux/skbuff.h:1286 [inline]\n netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]\n netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nTIPC bearer-related names including link names must be null-terminated\nstrings. If a link name which is not null-terminated is passed through\nnetlink, strstr() and similar functions can cause buffer overrun. This\ncauses the above issue.\r\n\r\nThis patch changes the nla_policy for bearer-related names from NLA_STRING\nto NLA_NUL_STRING. This resolves the issue by ensuring that only\nnull-terminated strings are accepted as bearer-related names.\r\n\r\nsyzbot reported similar uninit-value issue related to bearer names [2]. The\nroot cause of this issue is that a non-null-terminated bearer name was\npassed. This patch also resolved this issue.(CVE-2023-52845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhsr: Prevent use after free in prp_create_tagged_frame()\r\n\r\nThe prp_fill_rct() function can fail. In that situation, it frees the\nskb and returns NULL. Meanwhile on the success path, it returns the\noriginal skb. So it's straight forward to fix bug by using the returned\nvalue.(CVE-2023-52846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: bttv: fix use after free error due to btv->timeout timer\r\n\r\nThere may be some a race condition between timer function\nbttv_irq_timeout and bttv_remove. The timer is setup in\nprobe and there is no timer_delete operation in remove\nfunction. When it hit kfree btv, the function might still be\ninvoked, which will cause use after free bug.\r\n\r\nThis bug is found by static analysis, it may be false positive.\r\n\r\nFix it by adding del_timer_sync invoking to the remove function.\r\n\r\ncpu0 cpu1\n bttv_probe\n ->timer_setup\n ->bttv_set_dma\n ->mod_timer;\nbttv_remove\n ->kfree(btv);\n ->bttv_irq_timeout\n ->USE btv(CVE-2023-52847)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npadata: Fix refcnt handling in padata_free_shell()\r\n\r\nIn a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead\nto system UAF (Use-After-Free) issues. Due to the lengthy analysis of\nthe pcrypt_aead01 function call, I'll describe the problem scenario\nusing a simplified model:\r\n\r\nSuppose there's a user of padata named `user_function` that adheres to\nthe padata requirement of calling `padata_free_shell` after `serial()`\nhas been invoked, as demonstrated in the following code:\r\n\r\n```c\nstruct request {\n struct padata_priv padata;\n struct completion *done;\n};\r\n\r\nvoid parallel(struct padata_priv *padata) {\n do_something();\n}\r\n\r\nvoid serial(struct padata_priv *padata) {\n struct request *request = container_of(padata,\n \t\t\t\tstruct request,\n\t\t\t\tpadata);\n complete(request->done);\n}\r\n\r\nvoid user_function() {\n DECLARE_COMPLETION(done)\n padata->parallel = parallel;\n padata->serial = serial;\n padata_do_parallel();\n wait_for_completion(&done);\n padata_free_shell();\n}\n```\r\n\r\nIn the corresponding padata.c file, there's the following code:\r\n\r\n```c\nstatic void padata_serial_worker(struct work_struct *serial_work) {\n ...\n cnt = 0;\r\n\r\n while (!list_empty(&local_list)) {\n ...\n padata->serial(padata);\n cnt++;\n }\r\n\r\n local_bh_enable();\r\n\r\n if (refcount_sub_and_test(cnt, &pd->refcnt))\n padata_free_pd(pd);\n}\n```\r\n\r\nBecause of the high system load and the accumulation of unexecuted\nsoftirq at this moment, `local_bh_enable()` in padata takes longer\nto execute than usual. Subsequently, when accessing `pd->refcnt`,\n`pd` has already been released by `padata_free_shell()`, resulting\nin a UAF issue with `pd->refcnt`.\r\n\r\nThe fix is straightforward: add `refcount_dec_and_test` before calling\n`padata_free_pd` in `padata_free_shell`.(CVE-2023-52854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (axi-fan-control) Fix possible NULL pointer dereference\r\n\r\naxi_fan_control_irq_handler(), dependent on the private\naxi_fan_control_data structure, might be called before the hwmon\ndevice is registered. That will cause an \"Unable to handle kernel\nNULL pointer dereference\" error.(CVE-2023-52863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: possible buffer overflow\r\n\r\nBuffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is\nchecked after access.(CVE-2023-52867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: core: prevent potential string overflow\r\n\r\nThe dev->id value comes from ida_alloc() so it's a number between zero\nand INT_MAX. If it's too high then these sprintf()s will overflow.(CVE-2023-52868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/platform: Add check for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.(CVE-2023-52869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52876)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Have trace_event_file have ref counters\r\n\r\nThe following can crash the kernel:\r\n\r\n # cd /sys/kernel/tracing\n # echo 'p:sched schedule' > kprobe_events\n # exec 5>>events/kprobes/sched/enable\n # > kprobe_events\n # exec 5>&-\r\n\r\nThe above commands:\r\n\r\n 1. Change directory to the tracefs directory\n 2. Create a kprobe event (doesn't matter what one)\n 3. Open bash file descriptor 5 on the enable file of the kprobe event\n 4. Delete the kprobe event (removes the files too)\n 5. Close the bash file descriptor 5\r\n\r\nThe above causes a crash!\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000028\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 PTI\n CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n RIP: 0010:tracing_release_file_tr+0xc/0x50\r\n\r\nWhat happens here is that the kprobe event creates a trace_event_file\n\"file\" descriptor that represents the file in tracefs to the event. It\nmaintains state of the event (is it enabled for the given instance?).\nOpening the \"enable\" file gets a reference to the event \"file\" descriptor\nvia the open file descriptor. When the kprobe event is deleted, the file is\nalso deleted from the tracefs system which also frees the event \"file\"\ndescriptor.\r\n\r\nBut as the tracefs file is still opened by user space, it will not be\ntotally removed until the final dput() is called on it. But this is not\ntrue with the event \"file\" descriptor that is already freed. If the user\ndoes a write to or simply closes the file descriptor it will reference the\nevent \"file\" descriptor that was just freed, causing a use-after-free bug.\r\n\r\nTo solve this, add a ref count to the event \"file\" descriptor as well as a\nnew flag called \"FREED\". The \"file\" will not be freed until the last\nreference is released. But the FREE flag will be set when the event is\nremoved to prevent any more modifications to that event from happening,\neven if there's still a reference to the event \"file\" descriptor.(CVE-2023-52879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout\r\n\r\nWhile the rhashtable set gc runs asynchronously, a race allows it to\ncollect elements from anonymous sets with timeouts while it is being\nreleased from the commit path.\r\n\r\nMingi Cho originally reported this issue in a different path in 6.1.x\nwith a pipapo set with low timeouts which is not possible upstream since\n7395dfacfff6 (\"netfilter: nf_tables: use timestamp to check for set\nelement timeout\").\r\n\r\nFix this by setting on the dead flag for anonymous sets to skip async gc\nin this case.\r\n\r\nAccording to 08e4c8c5919f (\"netfilter: nf_tables: mark newset as dead on\ntransaction abort\"), Florian plans to accelerate abort path by releasing\nobjects via workqueue, therefore, this sets on the dead flag for abort\npath too.(CVE-2024-26643)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwireguard: netlink: access device through ctx instead of peer\r\n\r\nThe previous commit fixed a bug that led to a NULL peer->device being\ndereferenced. It's actually easier and faster performance-wise to\ninstead get the device from ctx->wg. This semantically makes more sense\ntoo, since ctx->wg->peer_allowedips.seq is compared with\nctx->allowedips_seq, basing them both in ctx. This also acts as a\ndefence in depth provision against freed peers.(CVE-2024-26950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: prevent kernel bug at submit_bh_wbc()\r\n\r\nFix a bug where nilfs_get_block() returns a successful status when\nsearching and inserting the specified block both fail inconsistently. If\nthis inconsistent behavior is not due to a previously fixed bug, then an\nunexpected race is occurring, so return a temporary error -EAGAIN instead.\r\n\r\nThis prevents callers such as __block_write_begin_int() from requesting a\nread into a buffer that is not mapped, which would cause the BUG_ON check\nfor the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/zcrypt: fix reference counting on zcrypt card objects\r\n\r\nTests with hot-plugging crytpo cards on KVM guests with debug\nkernel build revealed an use after free for the load field of\nthe struct zcrypt_card. The reason was an incorrect reference\nhandling of the zcrypt card object which could lead to a free\nof the zcrypt card object while it was still in use.\r\n\r\nThis is an example of the slab message:\r\n\r\n kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b\n kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43\n kernel: kmalloc_trace+0x3f2/0x470\n kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]\n kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]\n kernel: ap_device_probe+0x15c/0x290\n kernel: really_probe+0xd2/0x468\n kernel: driver_probe_device+0x40/0xf0\n kernel: __device_attach_driver+0xc0/0x140\n kernel: bus_for_each_drv+0x8c/0xd0\n kernel: __device_attach+0x114/0x198\n kernel: bus_probe_device+0xb4/0xc8\n kernel: device_add+0x4d2/0x6e0\n kernel: ap_scan_adapter+0x3d0/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43\n kernel: kfree+0x37e/0x418\n kernel: zcrypt_card_put+0x54/0x80 [zcrypt]\n kernel: ap_device_remove+0x4c/0xe0\n kernel: device_release_driver_internal+0x1c4/0x270\n kernel: bus_remove_device+0x100/0x188\n kernel: device_del+0x164/0x3c0\n kernel: device_unregister+0x30/0x90\n kernel: ap_scan_adapter+0xc8/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: kthread+0x150/0x168\n kernel: __ret_from_fork+0x3c/0x58\n kernel: ret_from_fork+0xa/0x30\n kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)\n kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88\n kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........\n kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.\n kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........\n kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ\n kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2\n kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)\n kernel: Call Trace:\n kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120\n kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140\n kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8\n kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8\n kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0\n kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8\n kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8\n kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590\n kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0\n kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0\n kernel: \n---truncated---(CVE-2024-26957)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfs: fix UAF in direct writes\r\n\r\nIn production we have been hitting the following warning consistently\r\n\r\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0\nWorkqueue: nfsiod nfs_direct_write_schedule_work [nfs]\nRIP: 0010:refcount_warn_saturate+0x9c/0xe0\nPKRU: 55555554\nCall Trace:\n \n ? __warn+0x9f/0x130\n ? refcount_warn_saturate+0x9c/0xe0\n ? report_bug+0xcc/0x150\n ? handle_bug+0x3d/0x70\n ? exc_invalid_op+0x16/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? refcount_warn_saturate+0x9c/0xe0\n nfs_direct_write_schedule_work+0x237/0x250 [nfs]\n process_one_work+0x12f/0x4a0\n worker_thread+0x14e/0x3b0\n ? ZSTD_getCParams_internal+0x220/0x220\n kthread+0xdc/0x120\n ? __btf_name_valid+0xa0/0xa0\n ret_from_fork+0x1f/0x30\r\n\r\nThis is because we're completing the nfs_direct_request twice in a row.\r\n\r\nThe source of this is when we have our commit requests to submit, we\nprocess them and send them off, and then in the completion path for the\ncommit requests we have\r\n\r\nif (nfs_commit_end(cinfo.mds))\n\tnfs_direct_write_complete(dreq);\r\n\r\nHowever since we're submitting asynchronous requests we sometimes have\none that completes before we submit the next one, so we end up calling\ncomplete on the nfs_direct_request twice.\r\n\r\nThe only other place we use nfs_generic_commit_list() is in\n__nfs_commit_inode, which wraps this call in a\r\n\r\nnfs_commit_begin();\nnfs_commit_end();\r\n\r\nWhich is a common pattern for this style of completion handling, one\nthat is also repeated in the direct code with get_dreq()/put_dreq()\ncalls around where we process events as well as in the completion paths.\r\n\r\nFix this by using the same pattern for the commit requests.\r\n\r\nBefore with my 200 node rocksdb stress running this warning would pop\nevery 10ish minutes. With my patch the stress test has been running for\nseveral hours without popping.(CVE-2024-26958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac802154: fix llsec key resources release in mac802154_llsec_key_del\r\n\r\nmac802154_llsec_key_del() can free resources of a key directly without\nfollowing the RCU rules for waiting before the end of a grace period. This\nmay lead to use-after-free in case llsec_lookup_key() is traversing the\nlist of keys in parallel with a key deletion:\r\n\r\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0\nModules linked in:\nCPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x162/0x2a0\nCall Trace:\n \n llsec_lookup_key.isra.0+0x890/0x9e0\n mac802154_llsec_encrypt+0x30c/0x9c0\n ieee802154_subif_start_xmit+0x24/0x1e0\n dev_hard_start_xmit+0x13e/0x690\n sch_direct_xmit+0x2ae/0xbc0\n __dev_queue_xmit+0x11dd/0x3c20\n dgram_sendmsg+0x90b/0xd60\n __sys_sendto+0x466/0x4c0\n __x64_sys_sendto+0xe0/0x1c0\n do_syscall_64+0x45/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nAlso, ieee802154_llsec_key_entry structures are not freed by\nmac802154_llsec_key_del():\r\n\r\nunreferenced object 0xffff8880613b6980 (size 64):\n comm \"iwpan\", pid 2176, jiffies 4294761134 (age 60.475s)\n hex dump (first 32 bytes):\n 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......\".......\n 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................\n backtrace:\n [] __kmem_cache_alloc_node+0x1e2/0x2d0\n [] kmalloc_trace+0x25/0xc0\n [] mac802154_llsec_key_add+0xac9/0xcf0\n [] ieee802154_add_llsec_key+0x5a/0x80\n [] nl802154_add_llsec_key+0x426/0x5b0\n [] genl_family_rcv_msg_doit+0x1fe/0x2f0\n [] genl_rcv_msg+0x531/0x7d0\n [] netlink_rcv_skb+0x169/0x440\n [] genl_rcv+0x28/0x40\n [] netlink_unicast+0x53c/0x820\n [] netlink_sendmsg+0x93b/0xe60\n [] ____sys_sendmsg+0xac5/0xca0\n [] ___sys_sendmsg+0x11d/0x1c0\n [] __sys_sendmsg+0xfa/0x1d0\n [] do_syscall_64+0x45/0xf0\n [] entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nHandle the proper resource release in the RCU callback function\nmac802154_llsec_key_del_rcu().\r\n\r\nNote that if llsec_lookup_key() finds a key, it gets a refcount via\nllsec_key_get() and locally copies key id from key_entry (which is a\nlist element). So it's safe to call llsec_key_put() and free the list\nentry after the RCU grace period elapses.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-msm8974: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: ubifs_symlink: Fix memleak of inode->i_link in error path\r\n\r\nFor error handling path in ubifs_symlink(), inode will be marked as\nbad first, then iput() is invoked. If inode->i_link is initialized by\nfscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't\nbe freed by callchain ubifs_free_inode -> fscrypt_free_inode in error\nhandling path, because make_bad_inode() has changed 'inode->i_mode' as\n'S_IFREG'.\nFollowing kmemleak is easy to be reproduced by injecting error in\nubifs_jnl_update() when doing symlink in encryption scenario:\n unreferenced object 0xffff888103da3d98 (size 8):\n comm \"ln\", pid 1692, jiffies 4294914701 (age 12.045s)\n backtrace:\n kmemdup+0x32/0x70\n __fscrypt_encrypt_symlink+0xed/0x1c0\n ubifs_symlink+0x210/0x300 [ubifs]\n vfs_symlink+0x216/0x360\n do_symlinkat+0x11a/0x190\n do_syscall_64+0x3b/0xe0\nThere are two ways fixing it:\n 1. Remove make_bad_inode() in error handling path. We can do that\n because ubifs_evict_inode() will do same processes for good\n symlink inode and bad symlink inode, for inode->i_nlink checking\n is before is_bad_inode().\n 2. Free inode->i_link before marking inode bad.\nMethod 2 is picked, it has less influence, personally, I think.(CVE-2024-26972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: Always flush async #PF workqueue when vCPU is being destroyed\r\n\r\nAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing its\ncompletion queue, e.g. when a VM and all its vCPUs is being destroyed.\nKVM must ensure that none of its workqueue callbacks is running when the\nlast reference to the KVM _module_ is put. Gifting a reference to the\nassociated VM prevents the workqueue callback from dereferencing freed\nvCPU/VM memory, but does not prevent the KVM module from being unloaded\nbefore the callback completes.\r\n\r\nDrop the misguided VM refcount gifting, as calling kvm_put_kvm() from\nasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will\nresult in deadlock. async_pf_execute() can't return until kvm_put_kvm()\nfinishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:\r\n\r\n WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]\n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass\n CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events async_pf_execute [kvm]\n RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]\n Call Trace:\n \n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \n ---[ end trace 0000000000000000 ]---\n INFO: task kworker/8:1:251 blocked for more than 120 seconds.\n Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000\n Workqueue: events async_pf_execute [kvm]\n Call Trace:\n \n __schedule+0x33f/0xa40\n schedule+0x53/0xc0\n schedule_timeout+0x12a/0x140\n __wait_for_common+0x8d/0x1d0\n __flush_work.isra.0+0x19f/0x2c0\n kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]\n kvm_arch_destroy_vm+0x78/0x1b0 [kvm]\n kvm_put_kvm+0x1c1/0x320 [kvm]\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \r\n\r\nIf kvm_clear_async_pf_completion_queue() actually flushes the workqueue,\nthen there's no need to gift async_pf_execute() a reference because all\ninvocations of async_pf_execute() will be forced to complete before the\nvCPU and its VM are destroyed/freed. And that in turn fixes the module\nunloading bug as __fput() won't do module_put() on the last vCPU reference\nuntil the vCPU has been freed, e.g. if closing the vCPU file also puts the\nlast reference to the KVM module.\r\n\r\nNote that kvm_check_async_pf_completion() may also take the work item off\nthe completion queue and so also needs to flush the work queue, as the\nwork will not be seen by kvm_clear_async_pf_completion_queue(). Waiting\non the workqueue could theoretically delay a vCPU due to waiting for the\nwork to complete, but that's a very, very small chance, and likely a very\nsmall delay. kvm_arch_async_page_present_queued() unconditionally makes a\nnew request, i.e. will effectively delay entering the guest, so the\nremaining work is really just:\r\n\r\n trace_kvm_async_pf_completed(addr, cr2_or_gpa);\r\n\r\n __kvm_vcpu_wake_up(vcpu);\r\n\r\n mmput(mm);\r\n\r\nand mmput() can't drop the last reference to the page tables if the vCPU is\nstill alive, i.e. the vCPU won't get stuck tearing down page tables.\r\n\r\nAdd a helper to do the flushing, specifically to deal with \"wakeup all\"\nwork items, as they aren't actually work items, i.e. are never placed in a\nworkqueue. Trying to flush a bogus workqueue entry rightly makes\n__flush_work() complain (kudos to whoever added that sanity check).\r\n\r\nNote, commit 5f6de5cbebee (\"KVM: Prevent module exit until al\n---truncated---(CVE-2024-26976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: check the inode number is not the invalid value of zero\r\n\r\nSyskiller has produced an out of bounds access in fill_meta_index().\r\n\r\nThat out of bounds access is ultimately caused because the inode\nhas an inode number with the invalid value of zero, which was not checked.\r\n\r\nThe reason this causes the out of bounds access is due to following\nsequence of events:\r\n\r\n1. Fill_meta_index() is called to allocate (via empty_meta_index())\n and fill a metadata index. It however suffers a data read error\n and aborts, invalidating the newly returned empty metadata index.\n It does this by setting the inode number of the index to zero,\n which means unused (zero is not a valid inode number).\r\n\r\n2. When fill_meta_index() is subsequently called again on another\n read operation, locate_meta_index() returns the previous index\n because it matches the inode number of 0. Because this index\n has been returned it is expected to have been filled, and because\n it hasn't been, an out of bounds access is performed.\r\n\r\nThis patch adds a sanity check which checks that the inode number\nis not zero when the inode is created and returns -EINVAL if it is.\r\n\r\n[phillip@squashfs.org.uk: whitespace fix]\n Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs: sysfs: Fix reference leak in sysfs_break_active_protection()\r\n\r\nThe sysfs_break_active_protection() routine has an obvious reference\nleak in its error path. If the call to kernfs_find_and_get() fails then\nkn will be NULL, so the companion sysfs_unbreak_active_protection()\nroutine won't get called (and would only cause an access violation by\ntrying to dereference kn->parent if it was called). As a result, the\nreference to kobj acquired at the start of the function will never be\nreleased.\r\n\r\nFix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspeakup: Avoid crash on very long word\r\n\r\nIn case a console is set up really large and contains a really long word\n(> 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial/pmac_zilog: Remove flawed mitigation for rx irq flood\r\n\r\nThe mitigation was intended to stop the irq completely. That may be\nbetter than a hard lock-up but it turns out that you get a crash anyway\nif you're using pmac_zilog as a serial console:\r\n\r\nttyPZ0: pmz: rx irq flood !\nBUG: spinlock recursion on CPU#0, swapper/0\r\n\r\nThat's because the pr_err() call in pmz_receive_chars() results in\npmz_console_write() attempting to lock a spinlock already locked in\npmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal\nBUG splat. The spinlock in question is the one in struct uart_port.\r\n\r\nEven when it's not fatal, the serial port rx function ceases to work.\nAlso, the iteration limit doesn't play nicely with QEMU, as can be\nseen in the bug report linked below.\r\n\r\nA web search for other reports of the error message \"pmz: rx irq flood\"\ndidn't produce anything. So I don't think this code is needed any more.\nRemove it.(CVE-2024-26999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: mxs-auart: add spinlock around changing cts state\r\n\r\nThe uart_handle_cts_change() function in serial_core expects the caller\nto hold uport->lock. For example, I have seen the below kernel splat,\nwhen the Bluetooth driver is loaded on an i.MX28 board.\r\n\r\n [ 85.119255] ------------[ cut here ]------------\n [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec\n [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs\n [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1\n [ 85.151396] Hardware name: Freescale MXS (Device Tree)\n [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]\n (...)\n [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4\n [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210\n (...)(CVE-2024-27000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: nv04: Fix out of bounds access\r\n\r\nWhen Output Resource (dcb->or) value is assigned in\nfabricate_dcb_output(), there may be out of bounds access to\ndac_users array in case dcb->or is zero because ffs(dcb->or) is\nused as index there.\nThe 'or' argument of fabricate_dcb_output() must be interpreted as a\nnumber of bit to set, not value.\r\n\r\nUtilize macros from 'enum nouveau_or' in calls instead of hardcoding.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix mirred deadlock on device recursion\r\n\r\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\r\n\r\n[..... other info removed for brevity....]\n[ 82.890906]\n[ 82.890906] ============================================\n[ 82.890906] WARNING: possible recursive locking detected\n[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W\n[ 82.890906] --------------------------------------------\n[ 82.890906] ping/418 is trying to acquire lock:\n[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] but task is already holding lock:\n[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] other info that might help us debug this:\n[ 82.890906] Possible unsafe locking scenario:\n[ 82.890906]\n[ 82.890906] CPU0\n[ 82.890906] ----\n[ 82.890906] lock(&sch->q.lock);\n[ 82.890906] lock(&sch->q.lock);\n[ 82.890906]\n[ 82.890906] *** DEADLOCK ***\n[ 82.890906]\n[..... other info removed for brevity....]\r\n\r\nExample setup (eth0->eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nAnother example(eth0->eth1->eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth1\r\n\r\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fix memleak in map from abort path\r\n\r\nThe delete set command does not rely on the transaction object for\nelement removal, therefore, a combination of delete element + delete set\nfrom the abort path could result in restoring twice the refcount of the\nmapping.\r\n\r\nCheck for inactive element in the next generation for the delete element\ncommand in the abort path, skip restoring state if next generation bit\nhas been already cleared. This is similar to the activate logic using\nthe set walk iterator.\r\n\r\n[ 6170.286929] ------------[ cut here ]------------\n[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287071] Modules linked in: [...]\n[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365\n[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f\n[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202\n[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000\n[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750\n[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55\n[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10\n[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100\n[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000\n[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0\n[ 6170.287962] Call Trace:\n[ 6170.287967] \n[ 6170.287973] ? __warn+0x9f/0x1a0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.288104] ? handle_bug+0x3c/0x70\n[ 6170.288112] ? exc_invalid_op+0x17/0x40\n[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20\n[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables](CVE-2024-27011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/rds: fix WARNING in rds_conn_connect_if_down\r\n\r\nIf connection isn't established yet, get_mr() will fail, trigger connection after\nget_mr().(CVE-2024-27024)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix to cover normal cluster write with cp_rwsem\r\n\r\nWhen we overwrite compressed cluster w/ normal cluster, we should\nnot unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data\nwill be corrupted if partial blocks were persisted before CP & SPOR,\ndue to cluster metadata wasn't updated atomically.(CVE-2024-27034)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix to guarantee persisting compressed blocks by CP\r\n\r\nIf data block in compressed cluster is not persisted with metadata\nduring checkpoint, after SPOR, the data may be corrupted, let's\nguarantee to write compressed page by checkpoint.(CVE-2024-27035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: zynq: Prevent null pointer dereference caused by kmalloc failure\r\n\r\nThe kmalloc() in zynq_clk_setup() will return null if the\nphysical memory has run out. As a result, if we use snprintf()\nto write data to the null address, the null pointer dereference\nbug will happen.\r\n\r\nThis patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'\r\n\r\nTell snprintf() to store at most 10 bytes in the output buffer\ninstead of 30.\r\n\r\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usb-storage: Prevent divide-by-0 error in isd200_ata_command\r\n\r\nThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS values\nin the ATA ID information to calculate cylinder and head values when\ncreating a CDB for READ or WRITE commands. The calculation involves\ndivision and modulus operations, which will cause a crash if either of\nthese values is 0. While this never happens with a genuine device, it\ncould happen with a flawed or subversive emulation, as reported by the\nsyzbot fuzzer.\r\n\r\nProtect against this possibility by refusing to bind to the device if\neither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID\ninformation is 0. This requires isd200_Initialization() to return a\nnegative error code when initialization fails; currently it always\nreturns 0 (even when there is an error).(CVE-2024-27059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: usbtv: Remove useless locks in usbtv_video_free()\r\n\r\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\r\n\r\nBefore 'c838530d230b' this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\r\n\r\n\n[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ttpci: fix two memleaks in budget_av_attach\r\n\r\nWhen saa7146_register_device and saa7146_vv_init fails, budget_av_attach\nshould free the resources it allocates, like the error-handling of\nttpci_budget_init does. Besides, there are two fixme comment refers to\nsuch deallocations.(CVE-2024-27073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: avoid stack overflow warnings with clang\r\n\r\nA previous patch worked around a KASAN issue in stv0367, now a similar\nproblem showed up with clang:\r\n\r\ndrivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]\n 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)\r\n\r\nRework the stv0367_writereg() function to be simpler and mark both\nregister access functions as noinline_for_stack so the temporary\ni2c_msg structures do not get duplicated on the stack when KASAN_STACK\nis enabled.(CVE-2024-27075)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix some memleaks in gssx_dec_option_array\r\n\r\nThe creds and oa->data need to be freed in the error-handling paths after\ntheir allocation. So this patch add these deallocations in the\ncorresponding paths.(CVE-2024-27388)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore: inode: Only d_invalidate() is needed\r\n\r\nUnloading a modular pstore backend with records in pstorefs would\ntrigger the dput() double-drop warning:\r\n\r\n WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410\r\n\r\nUsing the combo of d_drop()/dput() (as mentioned in\nDocumentation/filesystems/vfs.rst) isn't the right approach here, and\nleads to the reference counting problem seen above. Use d_invalidate()\nand update the code to not bother checking for error codes that can\nnever happen.\r\n\r\n---(CVE-2024-27389)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_flow_offload: reset dst in route object after setting up flow\r\n\r\ndst is transferred to the flow object, route object does not own it\nanymore. Reset dst in route object, otherwise if flow_offload_add()\nfails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Fixed overflow check in mi_enum_attr()(CVE-2024-27407)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Fix data-races around sysctl_net_busy_read\r\n\r\nWe need to protect the reader reading the sysctl value because the\nvalue can be changed concurrently.(CVE-2024-27419)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\nx86/fpu: Keep xfd_state in sync with MSR_IA32_XFD\nCommit 672365477ae8 (\"x86/fpu: Update XFD state where required\") and\ncommit 8bf26758ca96 (\"x86/fpu: Add XFD state to fpstate\") introduced a\nper CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in\norder to avoid unnecessary writes to the MSR.\nOn CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which\nwipes out any stale state. But the per CPU cached xfd value is not\nreset, which brings them out of sync.\nAs a consequence a subsequent xfd_update_state() might fail to update\nthe MSR which in turn can result in XRSTOR raising a #NM in kernel\nspace, which crashes the kernel.\nTo fix this, introduce xfd_set_state() to write xfd_state together\nwith MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.(CVE-2024-35801)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm snapshot: fix lockup in dm_exception_table_exit\r\n\r\nThere was reported lockup when we exit a snapshot with many exceptions.\nFix this by adding \"cond_resched\" to the loop that frees the exceptions.(CVE-2024-35805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\r\n\r\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.(CVE-2024-35806)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion\r\n\r\nThe first kiocb_set_cancel_fn() argument may point at a struct kiocb\nthat is not embedded inside struct aio_kiocb. With the current code,\ndepending on the compiler, the req->ki_ctx read happens either before\nthe IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such\nthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag\r\n\r\nOtherwise after the GTT bo is released, the GTT and gart space is freed\nbut amdgpu_ttm_backend_unbind will not clear the gart page table entry\nand leave valid mapping entry pointing to the stale system page. Then\nif GPU access the gart address mistakely, it will read undefined value\ninstead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nLoongArch: Define the __io_aw() hook as mmiowb()\r\n\r\nCommit fb24ea52f78e0d595852e (\"drivers: Remove explicit invocations of\nmmiowb()\") remove all mmiowb() in drivers, but it says:\r\n\r\n\"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with\nspin_unlock(). However, pairing each mmiowb() removal in this patch with\nthe corresponding call to spin_unlock() is not at all trivial, so there\nis a small chance that this change may regress any drivers incorrectly\nrelying on mmiowb() to order MMIO writes between CPUs using lock-free\nsynchronisation.\"\r\n\r\nThe mmio in radeon_ring_commit() is protected by a mutex rather than a\nspinlock, but in the mutex fastpath it behaves similar to spinlock. We\ncan add mmiowb() calls in the radeon driver but the maintainer says he\ndoesn't like such a workaround, and radeon is not the only example of\nmutex protected mmio.\r\n\r\nSo we should extend the mmiowb tracking system from spinlock to mutex,\nand maybe other locking primitives. This is not easy and error prone, so\nwe solve it in the architectural code, by simply defining the __io_aw()\nhook as mmiowb(). And we no longer need to override queued_spin_unlock()\nso use the generic definition.\r\n\r\nWithout this, we get such an error when run 'glxgears' on weak ordering\narchitectures such as LoongArch:\r\n\r\nradeon 0000:04:00.0: ring 0 stalled for more than 10324msec\nradeon 0000:04:00.0: ring 3 stalled for more than 10240msec\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)(CVE-2024-35818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: fix a double-free in arfs_create_groups\r\n\r\nWhen `in` allocated by kvzalloc fails, arfs_create_groups will free\nft->g and return an error. However, arfs_create_table, the only caller of\narfs_create_groups, will hold this error and call to\nmlx5e_destroy_flow_table, in which the ft->g will be freed again.(CVE-2024-35835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: bridge: replace physindev with physinif in nf_bridge_info\r\n\r\nAn skb can be added to a neigh->arp_queue while waiting for an arp\nreply. Where original skb's skb->dev can be different to neigh's\nneigh->dev. For instance in case of bridging dnated skb from one veth to\nanother, the skb would be added to a neigh->arp_queue of the bridge.\r\n\r\nAs skb->dev can be reset back to nf_bridge->physindev and used, and as\nthere is no explicit mechanism that prevents this physindev from been\nfreed under us (for instance neigh_flush_dev doesn't cleanup skbs from\ndifferent device's neigh queue) we can crash on e.g. this stack:\r\n\r\narp_process\n neigh_update\n skb = __skb_dequeue(&neigh->arp_queue)\n neigh_resolve_output(..., skb)\n ...\n br_nf_dev_xmit\n br_nf_pre_routing_finish_bridge_slow\n skb->dev = nf_bridge->physindev\n br_handle_frame_finish\r\n\r\nLet's use plain ifindex instead of net_device link. To peek into the\noriginal net_device we will use dev_get_by_index_rcu(). Thus either we\nget device and are safe to use it or we don't get it and drop skb.(CVE-2024-35839)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix reserve_cblocks counting error when out of space\r\n\r\nWhen a file only needs one direct_node, performing the following\noperations will cause the file to be unrepairable:\r\n\r\nunisoc # ./f2fs_io compress test.apk\nunisoc #df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.2M 100% /data\r\n\r\nunisoc # ./f2fs_io release_cblocks test.apk\n924\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 4.8M 100% /data\r\n\r\nunisoc # dd if=/dev/random of=file4 bs=1M count=3\n3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.8M 100% /data\r\n\r\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\r\n\r\nadb reboot\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n0\r\n\r\nThis is because the file has only one direct_node. After returning\nto -ENOSPC, reserved_blocks += ret will not be executed. As a result,\nthe reserved_blocks at this time is still 0, which is not the real\nnumber of reserved blocks. Therefore, fsck cannot be set to repair\nthe file.\r\n\r\nAfter this patch, the fsck flag will be set to fix this problem.\r\n\r\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.8M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\r\n\r\nadb reboot then fsck will be executed\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n924(CVE-2024-35844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neeprom: at24: fix memory corruption race condition\r\n\r\nIf the eeprom is not accessible, an nvmem device will be registered, the\nread will fail, and the device will be torn down. If another driver\naccesses the nvmem device after the teardown, it will reference\ninvalid memory.\r\n\r\nMove the failure point before registering the nvmem device.(CVE-2024-35848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix infinite recursion in fib6_dump_done().\r\n\r\nsyzkaller reported infinite recursive calls of fib6_dump_done() during\nnetlink socket destruction. [1]\r\n\r\nFrom the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then\nthe response was generated. The following recvmmsg() resumed the dump\nfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due\nto the fault injection. [0]\r\n\r\n 12:01:34 executing program 3:\n r0 = socket$nl_route(0x10, 0x3, 0x0)\n sendmsg$nl_route(r0, ... snip ...)\n recvmmsg(r0, ... snip ...) (fail_nth: 8)\r\n\r\nHere, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call\nof inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped\nreceiving the response halfway through, and finally netlink_sock_destruct()\ncalled nlk_sk(sk)->cb.done().\r\n\r\nfib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it\nis still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by\nnlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling\nitself recursively and hitting the stack guard page.\r\n\r\nTo avoid the issue, let's set the destructor after kzalloc().\r\n\r\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \n dump_stack_lvl (lib/dump_stack.c:117)\n should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)\n should_failslab (mm/slub.c:3733)\n kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)\n inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)\n rtnl_dump_all (net/core/rtnetlink.c:4029)\n netlink_dump (net/netlink/af_netlink.c:2269)\n netlink_recvmsg (net/netlink/af_netlink.c:1988)\n ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)\n ___sys_recvmsg (net/socket.c:2846)\n do_recvmmsg (net/socket.c:2943)\n __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)\r\n\r\n[1]:\nBUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)\nstack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)\nCode: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d980000 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3\nRDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358\nRBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000\nR13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68\nFS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n <#DF>\n \n \n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n ...\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n netlink_sock_destruct (net/netlink/af_netlink.c:401)\n __sk_destruct (net/core/sock.c:2177 (discriminator 2))\n sk_destruct (net/core/sock.c:2224)\n __sk_free (net/core/sock.c:2235)\n sk_free (net/core/sock.c:2246)\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.\n---truncated---(CVE-2024-35886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: discard table flag update with pending basechain deletion\r\n\r\nHook unregistration is deferred to the commit phase, same occurs with\nhook updates triggered by the table dormant flag. When both commands are\ncombined, this results in deleting a basechain while leaving its hook\nstill registered in the core.(CVE-2024-35897)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()\r\n\r\nnft_unregister_flowtable_type() within nf_flow_inet_module_exit() can\nconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().\nAnd thhere is not any protection when iterate over nf_tables_flowtables\nlist in __nft_flowtable_type_get(). Therefore, there is pertential\ndata-race of nf_tables_flowtables list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_flowtables list\nin __nft_flowtable_type_get(), and use rcu_read_lock() in the caller\nnft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbmon: prevent division by zero in fb_videomode_from_videomode()\r\n\r\nThe expression htotal * vtotal can have a zero value on\noverflow. It is necessary to prevent division by zero like in\nfb_var_to_videomode().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()\r\n\r\nThe call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an\nunsuccessful status. In such cases, the elsiocb is not issued, the\ncompletion is not called, and thus the elsiocb resource is leaked.\r\n\r\nCheck return value after calling lpfc_sli4_resume_rpi() and conditionally\nrelease the elsiocb resource.(CVE-2024-35930)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()\r\n\r\nThe unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,\nas it could be caused only by two impossible conditions:\r\n\r\n- at first the search key is set up to look for a chunk tree item, with\n offset -1, this is an inexact search and the key->offset will contain\n the correct offset upon a successful search, a valid chunk tree item\n cannot have an offset -1\r\n\r\n- after first successful search, the found_key corresponds to a chunk\n item, the offset is decremented by 1 before the next loop, it's\n impossible to find a chunk item there due to alignment and size\n constraints(CVE-2024-35936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/zone: Add a null pointer check to the psz_kmsg_read\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.(CVE-2024-35940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING\r\n\r\nsyzbot reported an illegal copy in xsk_setsockopt() [1]\r\n\r\nMake sure to validate setsockopt() @optlen parameter.\r\n\r\n[1]\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\nRead of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549\r\n\r\nCPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n copy_from_sockptr include/linux/sockptr.h:55 [inline]\n xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fb40587de69\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69\nRDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006\nRBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08\n \r\n\r\nAllocated by task 7549:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:3966 [inline]\n __kmalloc+0x233/0x4a0 mm/slub.c:3979\n kmalloc include/linux/slab.h:632 [inline]\n __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869\n do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nThe buggy address belongs to the object at ffff888028c6cde0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 1 bytes to the right of\n allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)\r\n\r\nThe buggy address belongs to the physical page:\npage:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c\nanon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xffffffff()\nraw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001\nraw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as allocated\npage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223\n set_page_owner include/linux/page_owner.h:31 [inline]\n post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533\n prep_new_page mm/page_alloc.c:\n---truncated---(CVE-2024-35976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: CPPC: Use access_width over bit_width for system memory accesses\r\n\r\nTo align with ACPI 6.3+, since bit_width can be any 8-bit value, it\ncannot be depended on to be always on a clean 8b boundary. This was\nuncovered on the Cobalt 100 platform.\r\n\r\nSError Interrupt on CPU26, code 0xbe000011 -- SError\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)\n pc : cppc_get_perf_caps+0xec/0x410\n lr : cppc_get_perf_caps+0xe8/0x410\n sp : ffff8000155ab730\n x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078\n x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff\n x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000\n x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff\n x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008\n x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006\n x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec\n x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028\n x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff\n x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000\n Kernel panic - not syncing: Asynchronous SError Interrupt\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted\n5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n Call trace:\n dump_backtrace+0x0/0x1e0\n show_stack+0x24/0x30\n dump_stack_lvl+0x8c/0xb8\n dump_stack+0x18/0x34\n panic+0x16c/0x384\n add_taint+0x0/0xc0\n arm64_serror_panic+0x7c/0x90\n arm64_is_fatal_ras_serror+0x34/0xa4\n do_serror+0x50/0x6c\n el1h_64_error_handler+0x40/0x74\n el1h_64_error+0x7c/0x80\n cppc_get_perf_caps+0xec/0x410\n cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]\n cpufreq_online+0x2dc/0xa30\n cpufreq_add_dev+0xc0/0xd4\n subsys_interface_register+0x134/0x14c\n cpufreq_register_driver+0x1b0/0x354\n cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]\n do_one_initcall+0x50/0x250\n do_init_module+0x60/0x27c\n load_module+0x2300/0x2570\n __do_sys_finit_module+0xa8/0x114\n __arm64_sys_finit_module+0x2c/0x3c\n invoke_syscall+0x78/0x100\n el0_svc_common.constprop.0+0x180/0x1a0\n do_el0_svc+0x84/0xa0\n el0_svc+0x2c/0xc0\n el0t_64_sync_handler+0xa4/0x12c\n el0t_64_sync+0x1a4/0x1a8\r\n\r\nInstead, use access_width to determine the size and use the offset and\nwidth to shift and mask the bits to read/write out. Make sure to add a\ncheck for system memory since pcc redefines the access_width to\nsubspace id.\r\n\r\nIf access_width is not set, then fall back to using bit_width.\r\n\r\n[ rjw: Subject and changelog edits, comment adjustments ](CVE-2024-35995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up\r\n\r\nThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.\nHowever, this is not necessary, because I2C core already has its own\nlocking for that.\r\n\r\nMore importantly, this flag can cause a lock-up: if the flag is set in\ni2c_hid_xfer() and an interrupt happens, the interrupt handler\n(i2c_hid_irq) will check this flag and return immediately without doing\nanything, then the interrupt handler will be invoked again in an\ninfinite loop.\r\n\r\nSince interrupt handler is an RT task, it takes over the CPU and the\nflag-clearing task never gets scheduled, thus we have a lock-up.\r\n\r\nDelete this unnecessary flag.(CVE-2024-35997)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix incorrect list API usage\r\n\r\nBoth the function that migrates all the chunks within a region and the\nfunction that migrates all the entries within a chunk call\nlist_first_entry() on the respective lists without checking that the\nlists are not empty. This is incorrect usage of the API, which leads to\nthe following warning [1].\r\n\r\nFix by returning if the lists are empty as there is nothing to migrate\nin this case.\r\n\r\n[1]\nWARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0>\nModules linked in:\nCPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0\n[...]\nCall Trace:\n \n mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n (CVE-2024-36006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv4: check for NULL idev in ip_route_use_hint()\r\n\r\nsyzbot was able to trigger a NULL deref in fib_validate_source()\nin an old tree [1].\r\n\r\nIt appears the bug exists in latest trees.\r\n\r\nAll calls to __in_dev_get_rcu() must be checked for a NULL result.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425\nCode: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf\nRSP: 0018:ffffc900015fee40 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0\nRDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0\nRBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000\nR10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000\nFS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231\n ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327\n ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]\n ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638\n ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673\n __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]\n __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620\n __netif_receive_skb_list net/core/dev.c:5672 [inline]\n netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764\n netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816\n xdp_recv_frames net/bpf/test_run.c:257 [inline]\n xdp_test_run_batch net/bpf/test_run.c:335 [inline]\n bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363\n bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376\n bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736\n __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115\n __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199(CVE-2024-36008)", + "cves": [ + { + "id": "CVE-2023-52868", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52868", + "severity": "Medium" + }, + { + "id": "CVE-2024-35801", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35801", + "severity": "Medium" + }, + { + "id": "CVE-2024-36008", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36008", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1122": { + "id": "openEuler-SA-2023-1122", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1122", + "title": "An update for curl is now available for openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "cURL is a computer software project providing a library (libcurl) and command-line tool (curl) for transferring data using various protocols.\r\n\r\nSecurity Fix(es):\r\n\r\ncurl supports \"chained\" HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with different algorithms. The number of acceptable \"links\" in this \"decompression chain\" was capped, but the cap was implemented on a per-header basis allowing a malicious server to insert a virtually unlimited number of compression steps simply by using many headers. The use of such a decompression chain could result in a \"malloc bomb\", making curl end up spending enormous amounts of allocated heap memory, or trying to and returning out of memory errors.(CVE-2023-23916)", + "cves": [ + { + "id": "CVE-2023-23916", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23916", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1856": { + "id": "openEuler-SA-2023-1856", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1856", + "title": "An update for python-pillow is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS,openEuler-22.03-LTS-SP1 and openEuler-22.03-LTS-SP2", + "severity": "High", + "description": "Pillow is the friendly PIL fork by Alex Clark and Contributors. PIL is the Python Imaging \\ Library by Fredrik Lundh and Contributors. As of 2019, Pillow development is supported by Tidelift. %package -n python3-pillow Summary: Python 3 image processing library Provides: python3-imaging = -\r\n\r\nSecurity Fix(es):\r\n\r\nAn issue was discovered in Pillow before 10.0.0. It is a Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.(CVE-2023-44271)", + "cves": [ + { + "id": "CVE-2023-44271", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44271", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1737": { + "id": "openEuler-SA-2023-1737", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1737", + "title": "An update for openjdk-11 is now available for openEuler-20.03-LTS-SP1", + "severity": "High", + "description": "The OpenJDK runtime environment.\r\n\r\nSecurity Fix(es):\r\n\r\nAn issue was discovered in function ciMethodBlocks::make_block_at in Oracle JDK (HotSpot VM) 11, 17 and OpenJDK (HotSpot VM) 8, 11, 17, allows attackers to cause a denial of service.(CVE-2022-40433)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and 22.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via DTLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2023-21835)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Sound). Supported versions that are affected are Oracle Java SE: 8u351, 8u351-perf, 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and 22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21843)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).(CVE-2023-21930)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21937)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and 22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21938)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21939)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.9 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).(CVE-2023-21954)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H).(CVE-2023-21967)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-21968)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).(CVE-2023-22006)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Utility). Supported versions that are affected are Oracle Java SE: 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2023-22036)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.1 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).(CVE-2023-22041)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2023-22045)\r\n\r\nVulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and 20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2023-22049)", + "cves": [ + { + "id": "CVE-2023-22049", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22049", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-2049": { + "id": "openEuler-SA-2022-2049", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-2049", + "title": "An update for swtpm is now available for openEuler-22.03-LTS", + "severity": "Medium", + "description": "TPM emulator built on libtpms providing TPM functionality for QEMU VMs\r\n\r\nSecurity Fix(es):\r\n\r\nswtpm is a libtpms-based TPM emulator with socket, character device, and Linux CUSE interface. Versions prior to 0.5.3, 0.6.2, and 0.7.1 are vulnerable to out-of-bounds read. A specially crafted header of swtpm's state, where the blobheader's hdrsize indicator has an invalid value, may cause an out-of-bounds access when the byte array representing the state of the TPM is accessed. This will likely crash swtpm or prevent it from starting since the state cannot be understood. Users should upgrade to swtpm v0.5.3, v0.6.2, or v0.7.1 to receive a patch. There are currently no known workarounds.(CVE-2022-23645)", + "cves": [ + { + "id": "CVE-2022-23645", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23645", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2024-1252": { + "id": "openEuler-SA-2024-1252", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1252", + "title": "An update for json-path is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS,openEuler-22.03-LTS-SP1,openEuler-22.03-LTS-SP2 and openEuler-22.03-LTS-SP3", + "severity": "Medium", + "description": "Java DSL for reading and testing JSON documents.\r\n\r\nSecurity Fix(es):\r\n\r\njson-path v2.8.0 was discovered to contain a stack overflow via the Criteria.parse() method.(CVE-2023-51074)", + "cves": [ + { + "id": "CVE-2023-51074", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51074", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1481": { + "id": "openEuler-SA-2023-1481", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1481", + "title": "An update for openssl is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS,openEuler-22.03-LTS-SP1 and openEuler-22.03-LTS-SP2", + "severity": "Medium", + "description": "OpenSSL is a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols.\r\n\r\nSecurity Fix(es):\r\n\r\nIssue summary: Checking excessively long DH keys or parameters may be very slow.\r\n\r\nImpact summary: Applications that use the functions DH_check(), DH_check_ex()\nor EVP_PKEY_param_check() to check a DH key or DH parameters may experience long\ndelays. Where the key or parameters that are being checked have been obtained\nfrom an untrusted source this may lead to a Denial of Service.\r\n\r\nThe function DH_check() performs various checks on DH parameters. After fixing\nCVE-2023-3446 it was discovered that a large q parameter value can also trigger\nan overly long computation during some of these checks. A correct q value,\nif present, cannot be larger than the modulus p parameter, thus it is\nunnecessary to perform these checks if q is larger than p.\r\n\r\nAn application that calls DH_check() and supplies a key or parameters obtained\nfrom an untrusted source could be vulnerable to a Denial of Service attack.\r\n\r\nThe function DH_check() is itself called by a number of other OpenSSL functions.\nAn application calling any of those other functions may similarly be affected.\nThe other functions affected by this are DH_check_ex() and\nEVP_PKEY_param_check().\r\n\r\nAlso vulnerable are the OpenSSL dhparam and pkeyparam command line applications\nwhen using the \"-check\" option.\r\n\r\nThe OpenSSL SSL/TLS implementation is not affected by this issue.\r\n\r\nThe OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.(CVE-2023-3817)", + "cves": [ + { + "id": "CVE-2023-3817", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3817", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1271": { + "id": "openEuler-SA-2023-1271", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1271", + "title": "An update for php is now available for openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "PHP is an HTML-embedded scripting language. PHP attempts to make it easy for developers to write dynamically generated web pages. PHP also offers built-in database integration for several commercial and non-commercial database management systems, so writing a database-enabled webpage with PHP is fairly simple. The most common use of PHP coding is probably as a replacement for CGI scripts.The php package contains the module (often referred to as mod_php) which adds support for the PHP language to Apache HTTP Server.\r\n\r\nSecurity Fix(es):\r\n\r\nIn PHP versions before 7.4.31, 8.0.24 and 8.1.11, the vulnerability enables network and same-site attackers to set a standard insecure cookie in the victim's browser which is treated as a `__Host-` or `__Secure-` cookie by PHP applications.(CVE-2022-31629)\r\n\r\nIn PHP versions before 7.4.31, 8.0.24 and 8.1.11, the phar uncompressor code would recursively uncompress \"quines\" gzip files, resulting in an infinite loop.(CVE-2022-31628)", + "cves": [ + { + "id": "CVE-2022-31628", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31628", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1175": { + "id": "openEuler-SA-2023-1175", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1175", + "title": "An update for epiphany is now available for openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "Epiphany is the web browser for the GNOME desktop. Its goal is to be simple and easy to use. Epiphany ties together many GNOME components in order to let you focus on the Web content, instead of the browser application.\r\n\r\nSecurity Fix(es):\r\n\r\nIn Epiphany (aka GNOME Web) through 43.0, untrusted web content can trick users into exfiltrating passwords, because autofill occurs in sandboxed contexts.(CVE-2023-26081)", + "cves": [ + { + "id": "CVE-2023-26081", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26081", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-2027": { + "id": "openEuler-SA-2022-2027", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-2027", + "title": "An update for kernel is now available for openEuler-22.03-LTS", + "severity": "Medium", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn rndis_set_response of rndis.c, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege if a malicious USB device is attached with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-239842288References: Upstream kernel(CVE-2022-20423)", + "cves": [ + { + "id": "CVE-2022-20423", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20423", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2022-1546": { + "id": "openEuler-SA-2022-1546", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1546", + "title": "An update for nodejs-jison is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP2 and openEuler-20.03-LTS-SP3", + "severity": "Critical", + "description": "A parser generator with Bison's API.\r\n\r\nSecurity Fix(es):\r\n\r\nInsufficient input validation in npm package `jison` <= 0.4.18 may lead to OS command injection attacks.(CVE-2020-8178)", + "cves": [ + { + "id": "CVE-2020-8178", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8178", + "severity": "Critical" + } + ] + }, + "openEuler-SA-2024-1442": { + "id": "openEuler-SA-2024-1442", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1442", + "title": "An update for libgsasl is now available for openEuler-20.03-LTS-SP4", + "severity": "High", + "description": "The library includes support for the SASL framework and at least partial support for the CRAM-MD5, EXTERNAL, GSSAPI, ANONYMOUS, PLAIN, SECURID, DIGEST-MD5, LOGIN, and NTLM mechanisms.\r\n\r\nSecurity Fix(es):\r\n\r\nGNU SASL libgsasl server-side read-out-of-bounds with malicious authenticated GSS-API client(CVE-2022-2469)", + "cves": [ + { + "id": "CVE-2022-2469", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2469", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1557": { + "id": "openEuler-SA-2023-1557", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1557", + "title": "An update for clamav is now available for openEuler-20.03-LTS-SP1", + "severity": "High", + "description": "Clam AntiVirus (clamav) is an open source antivirus engine for detecting trojans, viruses, malware and other malicious threats. The main purpose of this software is the integration with mail servers (attachment scanning). The package provides a flexible and scalable multi-threaded daemon, a command line scanner, and a tool for automatic updating via Internet. The programs are based on a shared library distributed with the Clam AntiVirus package, which you can use with your own software. he virus database is based on the virus database from OpenAntiVirus, but contains additional signatures and is KEPT UP TO DATE.\r\n\r\nSecurity Fix(es):\r\n\r\nA vulnerability in the filesystem image parser for Hierarchical File System Plus (HFS+) of ClamAV could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.\r\n\r This vulnerability is due to an incorrect check for completion when a file is decompressed, which may result in a loop condition that could cause the affected software to stop responding. An attacker could exploit this vulnerability by submitting a crafted HFS+ filesystem image to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to cause the ClamAV scanning process to stop responding, resulting in a DoS condition on the affected software and consuming available system resources.\r\n\r For a description of this vulnerability, see the ClamAV blog .(CVE-2023-20197)", + "cves": [ + { + "id": "CVE-2023-20197", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20197", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1298": { + "id": "openEuler-SA-2023-1298", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1298", + "title": "An update for qemu is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3 and openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "\r\n\r\nSecurity Fix(es):\r\n\r\nA flaw was found in the QEMU implementation of VMWare's paravirtual RDMA device. This flaw allows a crafted guest driver to execute HW commands when shared buffers are not yet allocated, potentially leading to a use-after-free condition.(CVE-2022-1050)", + "cves": [ + { + "id": "CVE-2022-1050", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1050", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1884": { + "id": "openEuler-SA-2023-1884", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1884", + "title": "An update for vim is now available for openEuler-20.03-LTS-SP3", + "severity": "Low", + "description": "Vim is an advanced text editor that seeks to provide the power of the de-facto Unix editor 'Vi', with a more complete feature set. Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems.\r\n\r\nSecurity Fix(es):\r\n\r\nVim is an open source command line text editor. When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. This issue has been addressed in commit `25aabc2b` which has been included in release version 9.0.2106. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-48231)\r\n\r\nVim is an open source command line text editor. If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `ac6378773` which has been included in release version 9.0.2108. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-48233)\r\n\r\nVim is an open source command line text editor. When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `58f9befca1` which has been included in release version 9.0.2109. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-48234)\r\n\r\nVim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause an\noverflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `060623e` which has been included in release version 9.0.2110. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-48235)\r\n\r\nVim is an open source command line text editor. When using the z= command, the user may overflow the count with values larger\nthan MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. This vulnerability has been addressed in commit `73b2d379` which has been included in release version 9.0.2111. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-48236)\r\n\r\nVim is an open source command line text editor. In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `6bf131888` which has been included in version 9.0.2112. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-48237)\r\n\r\nVim is a UNIX editor that, prior to version 9.0.2121, has a heap-use-after-free vulnerability. When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. Version 9.0.2121 contains a fix for this issue.(CVE-2023-48706)", + "cves": [ + { + "id": "CVE-2023-48706", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48706", + "severity": "Low" + } + ] + }, + "openEuler-SA-2023-1084": { + "id": "openEuler-SA-2023-1084", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1084", + "title": "An update for kernel is now available for openEuler-22.03-LTS", + "severity": "High", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nA double-free memory flaw was found in the Linux kernel. The Intel GVT-g graphics driver triggers VGA card system resource overload, causing a fail in the intel_gvt_dma_map_guest_page function. This issue could allow a local user to crash the system.(CVE-2022-3707)\r\n\r\nA NULL pointer dereference flaw was found in rawv6_push_pending_frames in net/ipv6/raw.c in the network subcomponent in the Linux kernel. This flaw causes the system to crash.(CVE-2023-0394)\r\n\r\nA use-after-free flaw was found in qdisc_graft in net/sched/sch_api.c in the Linux Kernel due to a race problem leading to a denial-of-service problem. \r\n\r\nReference:\nhttps://lore.kernel.org/all/20221018203258.2793282-1-edumazet@google.com/\r\n\r\n\nCrash:\n BUG: KASAN: use-after-free in __tcf_qdisc_find.part.0+0xa3a/0xac0 net/sched/cls_api.c:1066\n Read of size 4 at addr ffff88802065e038 by task syz-executor.4/21027\n \n CPU: 0 PID: 21027 Comm: syz-executor.4 Not tainted 6.0.0-rc3-syzkaller-00363-g7726d4c3e60b #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022\n Call Trace:\n \n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:317 [inline]\n print_report.cold+0x2ba/0x719 mm/kasan/report.c:433\n kasan_report+0xb1/0x1e0 mm/kasan/report.c:495\n __tcf_qdisc_find.part.0+0xa3a/0xac0 net/sched/cls_api.c:1066\n __tcf_qdisc_find net/sched/cls_api.c:1051 [inline]\n tc_new_tfilter+0x34f/0x2200 net/sched/cls_api.c:2018\n rtnetlink_rcv_msg+0x955/0xca0 net/core/rtnetlink.c:6081\n netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:734\n ____sys_sendmsg+0x6eb/0x810 net/socket.c:2482\n ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536\n __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x7f5efaa89279(CVE-2023-0590)", + "cves": [ + { + "id": "CVE-2023-0590", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0590", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2022-1552": { + "id": "openEuler-SA-2022-1552", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1552", + "title": "An update for mysql5 is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP2 and openEuler-20.03-LTS-SP3", + "severity": "Medium", + "description": "MySQL is a multi-user, multi-threaded SQL database server. MySQL is a client/server implementation consisting of a server daemon (mysqld) and many different client programs and libraries. The base package contains the standard MySQL client programs and generic MySQL files. \r\n\r\nSecurity Fix(es):\r\n\r\nVulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 5.7.31 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).(CVE-2020-14760)\r\n\r\nVulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Encryption). Supported versions that are affected are 5.6.45 and prior and 5.7.27 and prior. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.0 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2019-2910)\r\n\r\nVulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Encryption). Supported versions that are affected are 5.6.45 and prior and 5.7.27 and prior. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.0 Base Score 5.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2019-2924)\r\n\r\nVulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Audit Log). Supported versions that are affected are 5.7.26 and prior and 8.0.16 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.0 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2019-2741)\r\n\r\nVulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Encryption). Supported versions that are affected are 5.6.45 and prior and 5.7.27 and prior. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.0 Base Score 5.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2019-2922)\r\n\r\nVulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Audit Plug-in). Supported versions that are affected are 5.7.26 and prior and 8.0.16 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data as well as unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.0 Base Score 3.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N).(CVE-2019-2791)\r\n\r\nVulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Replication). Supported versions that are affected are 5.7.23 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.0 Base Score 5.4 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L).(CVE-2019-2731)\r\n\r\nVulnerability in the MySQL Server product of Oracle MySQL (component: Server: Pluggable Auth). Supported versions that are affected are 5.7.28 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.0 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2020-2790)\r\n\r\nVulnerability in the MySQL Client product of Oracle MySQL (component: C API). Supported versions that are affected are 5.6.47 and prior, 5.7.29 and prior and 8.0.18 and prior. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Client. Successful attacks of this vulnerability can result in unauthorized read access to a subset of MySQL Client accessible data. CVSS 3.0 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2020-2922)\r\n\r\nVulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Audit Plug-in). Supported versions that are affected are 5.7.25 and prior and 8.0.15 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.0 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2019-2566)\r\n\r\nVulnerability in the MySQL Server product of Oracle MySQL (component: Server: PAM Auth Plugin). Supported versions that are affected are 5.7.32 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2021-2014)\r\n\r\nVulnerability in the MySQL Server product of Oracle MySQL (component: Server: Compiling). Supported versions that are affected are 5.7.28 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.0 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2020-2806)", + "cves": [ + { + "id": "CVE-2020-2806", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2806", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1820": { + "id": "openEuler-SA-2023-1820", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1820", + "title": "An update for GraphicsMagick is now available for openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "GraphicsMagick is the swiss army knife of image processing. Comprised of 267K physical lines (according to David A. Wheeler's SLOCCount) of source code in the base package (or 1,225K including 3rd party libraries) it provides a robust and efficient collection of tools and libraries which support reading, writing, and manipulating an image in over 89 major formats including important formats like DPX, GIF, JPEG, JPEG-2000, PNG, PDF, PNM, TIFF, and WebP.\r\n\r\nSecurity Fix(es):\r\n\r\nBuffer Overflow vulnerability in WritePCXImage function in pcx.c in GraphicsMagick 1.4 allows remote attackers to cause a denial of service via converting of crafted image file to pcx format.(CVE-2020-21679)", + "cves": [ + { + "id": "CVE-2020-21679", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-21679", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2024-1568": { + "id": "openEuler-SA-2024-1568", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1568", + "title": "An update for kernel is now available for openEuler-20.03-LTS-SP4", + "severity": "Medium", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Fix scsi_mode_sense() buffer length handling\r\n\r\nSeveral problems exist with scsi_mode_sense() buffer length handling:\r\n\r\n 1) The allocation length field of the MODE SENSE(10) command is 16-bits,\n occupying bytes 7 and 8 of the CDB. With this command, access to mode\n pages larger than 255 bytes is thus possible. However, the CDB\n allocation length field is set by assigning len to byte 8 only, thus\n truncating buffer length larger than 255.\r\n\r\n 2) If scsi_mode_sense() is called with len smaller than 8 with\n sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length\n is increased to 8 and 4 respectively, and the buffer is zero filled\n with these increased values, thus corrupting the memory following the\n buffer.\r\n\r\nFix these 2 problems by using put_unaligned_be16() to set the allocation\nlength field of MODE SENSE(10) CDB and by returning an error when len is\ntoo small.\r\n\r\nFurthermore, if len is larger than 255B, always try MODE SENSE(10) first,\neven if the device driver did not set sdev->use_10_for_ms. In case of\ninvalid opcode error for MODE SENSE(10), access to mode pages larger than\n255 bytes are not retried using MODE SENSE(6). To avoid buffer length\noverflows for the MODE_SENSE(10) case, check that len is smaller than 65535\nbytes.\r\n\r\nWhile at it, also fix the folowing:\r\n\r\n * Use get_unaligned_be16() to retrieve the mode data length and block\n descriptor length fields of the mode sense reply header instead of using\n an open coded calculation.\r\n\r\n * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable\n Block Descriptor, which is the opposite of what the dbd argument\n description was.(CVE-2021-47182)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niavf: free q_vectors before queues in iavf_disable_vf\r\n\r\niavf_free_queues() clears adapter->num_active_queues, which\niavf_free_q_vectors() relies on, so swap the order of these two function\ncalls in iavf_disable_vf(). This resolves a panic encountered when the\ninterface is disabled and then later brought up again after PF\ncommunication is restored.(CVE-2021-47201)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()\r\n\r\nWhen parsing the txq list in lpfc_drain_txq(), the driver attempts to pass\nthe requests to the adapter. If such an attempt fails, a local \"fail_msg\"\nstring is set and a log message output. The job is then added to a\ncompletions list for cancellation.\r\n\r\nProcessing of any further jobs from the txq list continues, but since\n\"fail_msg\" remains set, jobs are added to the completions list regardless\nof whether a wqe was passed to the adapter. If successfully added to\ntxcmplq, jobs are added to both lists resulting in list corruption.\r\n\r\nFix by clearing the fail_msg string after adding a job to the completions\nlist. This stops the subsequent jobs from being added to the completions\nlist unless they had an appropriate failure.(CVE-2021-47203)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\r\n\r\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference.(CVE-2021-47211)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: advansys: Fix kernel pointer leak\r\n\r\nPointers should be printed with %p or %px rather than cast to 'unsigned\nlong' and printed with %lx.\r\n\r\nChange %lx to %p to print the hashed pointer.(CVE-2021-47216)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails\r\n\r\nCheck for a valid hv_vp_index array prior to derefencing hv_vp_index when\nsetting Hyper-V's TSC change callback. If Hyper-V setup failed in\nhyperv_init(), the kernel will still report that it's running under\nHyper-V, but will have silently disabled nearly all functionality.\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000010\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] SMP\n CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:set_hv_tscchange_cb+0x15/0xa0\n Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08\n ...\n Call Trace:\n kvm_arch_init+0x17c/0x280\n kvm_init+0x31/0x330\n vmx_init+0xba/0x13a\n do_one_initcall+0x41/0x1c0\n kernel_init_freeable+0x1f2/0x23b\n kernel_init+0x16/0x120\n ret_from_fork+0x22/0x30(CVE-2021-47217)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: hub: Guard against accesses to uninitialized BOS descriptors\r\n\r\nMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h\naccess fields inside udev->bos without checking if it was allocated and\ninitialized. If usb_get_bos_descriptor() fails for whatever\nreason, udev->bos will be NULL and those accesses will result in a\ncrash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000018\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 \nHardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:hub_port_reset+0x193/0x788\nCode: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9\nRSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310\nRDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840\nRBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0\nCall Trace:\nhub_event+0x73f/0x156e\n? hub_activate+0x5b7/0x68f\nprocess_one_work+0x1a2/0x487\nworker_thread+0x11a/0x288\nkthread+0x13a/0x152\n? process_one_work+0x487/0x487\n? kthread_associate_blkcg+0x70/0x70\nret_from_fork+0x1f/0x30\r\n\r\nFall back to a default behavior if the BOS descriptor isn't accessible\nand skip all the functionalities that depend on it: LPM support checks,\nSuper Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix race between mmput() and do_exit()\r\n\r\nTask A calls binder_update_page_range() to allocate and insert pages on\na remote address space from Task B. For this, Task A pins the remote mm\nvia mmget_not_zero() first. This can race with Task B do_exit() and the\nfinal mmput() refcount decrement will come from Task A.\r\n\r\n Task A | Task B\n ------------------+------------------\n mmget_not_zero() |\n | do_exit()\n | exit_mm()\n | mmput()\n mmput() |\n exit_mmap() |\n remove_vma() |\n fput() |\r\n\r\nIn this case, the work of ____fput() from Task B is queued up in Task A\nas TWA_RESUME. So in theory, Task A returns to userspace and the cleanup\nwork gets executed. However, Task A instead sleep, waiting for a reply\nfrom Task B that never comes (it's dead).\r\n\r\nThis means the binder_deferred_release() is blocked until an unrelated\nbinder event forces Task A to go back to userspace. All the associated\ndeath notifications will also be delayed until then.\r\n\r\nIn order to fix this use mmput_async() that will schedule the work in\nthe corresponding mm->async_put_work WQ instead of Task A.(CVE-2023-52609)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: Drop support for ETH_P_TR_802_2.\r\n\r\nsyzbot reported an uninit-value bug below. [0]\r\n\r\nllc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2\n(0x0011), and syzbot abused the latter to trigger the bug.\r\n\r\n write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', \"90e5dd\"}}}}, 0x16)\r\n\r\nllc_conn_handler() initialises local variables {saddr,daddr}.mac\nbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes\nthem to __llc_lookup().\r\n\r\nHowever, the initialisation is done only when skb->protocol is\nhtons(ETH_P_802_2), otherwise, __llc_lookup_established() and\n__llc_lookup_listener() will read garbage.\r\n\r\nThe missing initialisation existed prior to commit 211ed865108e\n(\"net: delete all instances of special processing for token ring\").\r\n\r\nIt removed the part to kick out the token ring stuff but forgot to\nclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().\r\n\r\nLet's remove llc_tr_packet_type and complete the deprecation.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90\n __llc_lookup_established+0xe9d/0xf90\n __llc_lookup net/llc/llc_conn.c:611 [inline]\n llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\n __netif_receive_skb_one_core net/core/dev.c:5527 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641\n netif_receive_skb_internal net/core/dev.c:5727 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5786\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x8ef/0x1490 fs/read_write.c:584\n ksys_write+0x20f/0x4c0 fs/read_write.c:637\n __do_sys_write fs/read_write.c:649 [inline]\n __se_sys_write fs/read_write.c:646 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:646\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nLocal variable daddr created at:\n llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\r\n\r\nCPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: make llc_ui_sendmsg() more robust against bonding changes\r\n\r\nsyzbot was able to trick llc_ui_sendmsg(), allocating an skb with no\nheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]\r\n\r\nLike some others, llc_ui_sendmsg() releases the socket lock before\ncalling sock_alloc_send_skb().\nThen it acquires it again, but does not redo all the sanity checks\nthat were performed.\r\n\r\nThis fix:\r\n\r\n- Uses LL_RESERVED_SPACE() to reserve space.\n- Check all conditions again after socket lock is held again.\n- Do not account Ethernet header for mtu limitation.\r\n\r\n[1]\r\n\r\nskbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0\r\n\r\n kernel BUG at net/core/skbuff.c:193 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : skb_panic net/core/skbuff.c:189 [inline]\n pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n lr : skb_panic net/core/skbuff.c:189 [inline]\n lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\nsp : ffff800096f97000\nx29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000\nx26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2\nx23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0\nx20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce\nx17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001\nx14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400\nx8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714\nx2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089\nCall trace:\n skb_panic net/core/skbuff.c:189 [inline]\n skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n skb_push+0xf0/0x108 net/core/skbuff.c:2451\n eth_header+0x44/0x1f8 net/ethernet/eth.c:83\n dev_hard_header include/linux/netdevice.h:3188 [inline]\n llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33\n llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85\n llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209\n llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270\n llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x194/0x274 net/socket.c:767\n splice_to_socket+0x7cc/0xd58 fs/splice.c:881\n do_splice_from fs/splice.c:933 [inline]\n direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142\n splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088\n do_splice_direct+0x20c/0x348 fs/splice.c:1194\n do_sendfile+0x4bc/0xc70 fs/read_write.c:1254\n __do_sys_sendfile64 fs/read_write.c:1322 [inline]\n __se_sys_sendfile64 fs/read_write.c:1308 [inline]\n __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308\n __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\n el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595\nCode: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: add sanity checks to rx zerocopy\r\n\r\nTCP rx zerocopy intent is to map pages initially allocated\nfrom NIC drivers, not pages owned by a fs.\r\n\r\nThis patch adds to can_map_frag() these additional checks:\r\n\r\n- Page must not be a compound one.\n- page->mapping must be NULL.\r\n\r\nThis fixes the panic reported by ZhangPeng.\r\n\r\nsyzbot was able to loopback packets built with sendfile(),\nmapping pages owned by an ext4 file to TCP rx zerocopy.\r\n\r\nr3 = socket$inet_tcp(0x2, 0x1, 0x0)\nmmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)\nr4 = socket$inet_tcp(0x2, 0x1, 0x0)\nbind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)\nconnect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)\nr5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\\x00',\n 0x181e42, 0x0)\nfallocate(r5, 0x0, 0x0, 0x85b8)\nsendfile(r4, r5, 0x0, 0x8ba0)\ngetsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,\n &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,\n 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)\nr6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\\x00',\n 0x181e42, 0x0)(CVE-2024-26640)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\r\n\r\nsyzbot found __ip6_tnl_rcv() could access unitiliazed data [1].\r\n\r\nCall pskb_inet_may_pull() to fix this, and initialize ipv6h\nvariable after this call as it can change skb->head.\r\n\r\n[1]\n BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727\n __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845\n ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888\n gre_rcv+0x143f/0x1870\n ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438\n ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n dst_input include/net/dst.h:461 [inline]\n ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core net/core/dev.c:5532 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646\n netif_receive_skb_internal net/core/dev.c:5732 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5791\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787\n tun_alloc_skb drivers/net/tun.c:1531 [inline]\n tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)", + "cves": [ + { + "id": "CVE-2024-26641", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26641", + "severity": "Low" + } + ] + }, + "openEuler-SA-2023-1616": { + "id": "openEuler-SA-2023-1616", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1616", + "title": "An update for kernel is now available for openEuler-22.03-LTS-SP2", + "severity": "High", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\n(CVE-2023-3865)\r\n\r\n(CVE-2023-3866)\r\n\r\nA use-after-free vulnerability was found in the siano smsusb module in the Linux kernel. The bug occurs during device initialization when the siano device is plugged in. This flaw allows a local user to crash the system, causing a denial of service condition.(CVE-2023-4132)\r\n\r\nA flaw was found in the exFAT driver of the Linux kernel. The vulnerability exists in the implementation of the file name reconstruction function, which is responsible for reading file name entries from a directory index and merging file name parts belonging to one file into a single long file name. Since the file name characters are copied into a stack variable, a local privileged attacker could use this flaw to overflow the kernel stack.(CVE-2023-4273)", + "cves": [ + { + "id": "CVE-2023-4273", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4273", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1956": { + "id": "openEuler-SA-2023-1956", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1956", + "title": "An update for freeradius is now available for openEuler-22.03-LTS", + "severity": "High", + "description": "Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA or Triple A) management for users who connect and use a network service.\r\n\r\nSecurity Fix(es):\r\n\r\nIn freeradius, the EAP-PWD function compute_password_element() leaks information about the password which allows an attacker to substantially reduce the size of an offline dictionary attack.(CVE-2022-41859)", + "cves": [ + { + "id": "CVE-2022-41859", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41859", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1639": { + "id": "openEuler-SA-2023-1639", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1639", + "title": "An update for python3 is now available for openEuler-20.03-LTS-SP1", + "severity": "High", + "description": "Python combines remarkable power with very clear syntax. It has modules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries, as well as to various windowing systems. New built-in modules are easily written in C or C++ (or other languages, depending on the chosen implementation). Python is also usable as an extension language for applications written in other languages that need easy-to-use scripting or automation interfaces.\r\n\r\nSecurity Fix(es):\r\n\r\nAn issue was discovered in compare_digest in Lib/hmac.py in Python through 3.9.1. Constant-time-defeating optimisations were possible in the accumulator variable in hmac.compare_digest.(CVE-2022-48566)", + "cves": [ + { + "id": "CVE-2022-48566", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48566", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-1908": { + "id": "openEuler-SA-2022-1908", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1908", + "title": "An update for curl is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3 and openEuler-22.03-LTS", + "severity": "Low", + "description": "cURL is a computer software project providing a library (libcurl) and command-line tool (curl) for transferring data using various protocols.\r\n\r\nSecurity Fix(es):\r\n\r\nWhen curl is used to retrieve and parse cookies from an HTTP(S) server, it accepts cookies using control codes (byte values below 32). When cookies that contain such control codes are later sent back to an HTTP(S) server, it might make the server return a 400 response. Effectively allowing a \"sister site\" to deny service to siblings.\r\n\r\nReference:\r\n\r\nhttps://curl.se/docs/CVE-2022-35252.html(CVE-2022-35252)", + "cves": [ + { + "id": "CVE-2022-35252", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35252", + "severity": "Low" + } + ] + }, + "openEuler-SA-2023-1282": { + "id": "openEuler-SA-2023-1282", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1282", + "title": "An update for ntp is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS and openEuler-22.03-LTS-SP1", + "severity": "Medium", + "description": "NTP is a protocol designed to synchronize the clocks of computers over a network, NTP version 4, a significant revision of the previous NTP standard, is the current development version. It is formalized by RFCs released by the IETF.\r\n\r\nSecurity Fix(es):\r\n\r\nmstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write in the cpbase.bind_addr.address_list.next when the list is empty.\r\n\r\nReferences:\nhttps://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=458e279f861d3f61796894cd158b780765a1569f\nhttps://www.openwall.com/lists/oss-security/2023/01/23/1(CVE-2023-1074)\r\n\r\nA flaw found in the Linux Kernel in RDS (Reliable Datagram Sockets) protocol. The rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Local user can trigger this with rds_message_put(). Type confusion leads to `struct rds_msg_zcopy_info *info` actually points to something else that is potentially controlled by local user.\nIt is known how to trigger this, which causes an OOB access, and a lock corruption.\r\n\r\nReference:\nhttps://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f753a68980cf4b59a80fe677619da2b1804f526d(CVE-2023-1078)\r\n\r\nA flaw found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function.\nWhile it will be often correct, as tuntap devices require CAP_NET_ADMIN, it may not always be the case, e.g., a non-root user only having that capability.\nThis would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters.\r\n\r\nReferences:\nhttps://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=66b2c338adce580dfce2199591e65e2bab889cff\nhttps://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a096ccca6e503a5c575717ff8a36ace27510ab0a(CVE-2023-1076)\r\n\r\nA flaw use after free in the Linux kernel integrated infrared receiver/transceiver driver was found in the way user detaching rc device. A local user could use this flaw to crash the system or potentially escalate their privileges on the system.(CVE-2023-1118)\n\nIn the Linux kernel before 6.1.13, there is a double free in net/mpls/af_mpls.c upon an allocation failure (for registering the sysctl table under a new location) during the renaming of a device.(CVE-2023-26545)", + "cves": [ + { + "id": "CVE-2023-26545", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26545", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1561": { + "id": "openEuler-SA-2023-1561", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1561", + "title": "An update for poppler is now available for openEuler-20.03-LTS-SP1,openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "poppler is a PDF rendering library.\r\n\r\nSecurity Fix(es):\r\n\r\nUncontrolled Recursion in pdfinfo, and pdftops in poppler 0.89.0 allows remote attackers to cause a denial of service via crafted input.(CVE-2020-23804)\r\n\r\nIn Poppler 22.07.0, PDFDoc::savePageAs in PDFDoc.c callows attackers to cause a denial-of-service (application crashes with SIGABRT) by crafting a PDF file in which the xref data structure is mishandled in getCatalog processing. Note that this vulnerability is caused by the incomplete patch of CVE-2018-20662.(CVE-2022-37050)\r\n\r\nAn issue was discovered in Poppler 22.07.0. There is a reachable abort which leads to denial of service because the main function in pdfunite.cc lacks a stream check before saving an embedded file.(CVE-2022-37051)\r\n\r\nA reachable Object::getString assertion in Poppler 22.07.0 allows attackers to cause a denial of service due to a failure in markObject.(CVE-2022-37052)\r\n\r\nAn issue was discovered in Poppler 22.08.0. There is a reachable assertion in Object.h, will lead to denial of service because PDFDoc::replacePageDict in PDFDoc.cc lacks a stream check before saving an embedded file.(CVE-2022-38349)", + "cves": [ + { + "id": "CVE-2022-38349", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38349", + "severity": "High" + } + ] + }, + "openEuler-SA-2021-1034": { + "id": "openEuler-SA-2021-1034", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2021-1034", + "title": "An update for djvulibre is now available for openEuler-20.03-LTS and openEuler-20.03-LTS-SP1", + "severity": "High", + "description": "DjVu is a set of compression technologies, a file format, and a software platform for the deliveryover the Web of digital documents, scanned documents, and high resolution images.DjVu documents download and display extremely quickly, and look exactly the same on all platforms with no compatibility problems due to fonts, colors, etc. DjVu can be seen as a superior alternative to PDF and PostScript for digital documents, to TIFF (and PDF) for scanned bitonal documents, to JPEG and JPEG2000 for photographs and pictures, and to GIF for large palettized images. DjVu is the only Web format that is practical for distributing high-resolution scanned documents in color.\n\r\nSecurity Fix(es):\n\r\nDjVuLibre 3.5.27 has a NULL pointer dereference in the function DJVU::filter_fv at IW44EncodeCodec.cpp.(CVE-2019-18804)\n\r\nDjVuLibre 3.5.27 allows attackers to cause a denial-of-service attack (application crash via an out-of-bounds read) by crafting a corrupted JB2 image file that is mishandled in JB2Dict::JB2Codec::get_direct_context in libdjvu/JB2Image.h because of a missing zero-bytes check in libdjvu/GBitmap.h.(CVE-2019-15145)\n\nIn DjVuLibre 3.5.27, DjVmDir.cpp in the DJVU reader component allows attackers to cause a denial-of-service (application crash in GStringRep::strdup in libdjvu/GString.cpp caused by a heap-based buffer over-read) by crafting a DJVU file.(CVE-2019-15142)\n\nIn DjVuLibre 3.5.27, the bitmap reader component allows attackers to cause a denial-of-service error (resource exhaustion caused by a GBitmap::read_rle_raw infinite loop) by crafting a corrupted image file, related to libdjvu/DjVmDir.cpp and libdjvu/GBitmap.cpp.(CVE-2019-15143)\n\nIn DjVuLibre 3.5.27, the sorting functionality allows attackers to cause a denial-of-service (application crash due to an Uncontrolled Recursion) by crafting a PBM image file that is mishandled in libdjvu/GContainer.h.(CVE-2019-15144)", + "cves": [ + { + "id": "CVE-2019-15144", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15144", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-1626": { + "id": "openEuler-SA-2022-1626", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1626", + "title": "An update for cifs-utils is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3 and openEuler-22.03-LTS", + "severity": "Medium", + "description": "The in-kernel CIFS filesystem is generally the preferred method for mounting SMB/CIFS shares on Linux. The in-kernel CIFS filesystem relies on a set of user-space tools. That package of tools is called cifs-utils.Although not really part of Samba proper, these tools were originally part of the Samba package. For several reasons, shipping these tools as part of Samba was problematic and it was deemed better to split them off into their own package.\r\n\r\nSecurity Fix(es):\r\n\r\ncifs-utils through 6.14, with verbose logging, can cause an information leak when a file contains = (equal sign) characters but is not a valid credentials file.(CVE-2022-29869)\n\nIn cifs-utils through 6.14, a stack-based buffer overflow when parsing the mount.cifs ip= command-line argument could lead to local attackers gaining root privileges.(CVE-2022-27239)", + "cves": [ + { + "id": "CVE-2022-27239", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27239", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2024-1192": { + "id": "openEuler-SA-2024-1192", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1192", + "title": "An update for mod_auth_openidc is now available for openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "This module enables an Apache 2.x web server to operate as an OpenID Connect Relying Party(RP) to an OpenID Connect Provider(OP).\r\n\r\nSecurity Fix(es):\r\n\r\nmod_auth_openidc is an OpenID Certified™ authentication and authorization module for the Apache 2.x HTTP server that implements the OpenID Connect Relying Party functionality. In affected versions missing input validation on mod_auth_openidc_session_chunks cookie value makes the server vulnerable to a denial of service (DoS) attack. An internal security audit has been conducted and the reviewers found that if they manipulated the value of the mod_auth_openidc_session_chunks cookie to a very large integer, like 99999999, the server struggles with the request for a long time and finally gets back with a 500 error. Making a few requests of this kind caused our server to become unresponsive. Attackers can craft requests that would make the server work very hard (and possibly become unresponsive) and/or crash with minimal effort. This issue has been addressed in version 2.4.15.2. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2024-24814)", + "cves": [ + { + "id": "CVE-2024-24814", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24814", + "severity": "High" + } + ] + }, + "openEuler-SA-2024-1840": { + "id": "openEuler-SA-2024-1840", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1840", + "title": "An update for openvpn is now available for openEuler-22.03-LTS-SP4,openEuler-22.03-LTS-SP1,openEuler-22.03-LTS-SP3,openEuler-20.03-LTS-SP4,openEuler-24.03-LTS", + "severity": "Medium", + "description": "OpenVPN is a full-featured open source SSL VPN solution that accommodates a wide range of configurations, including remote access, site-to-site VPNs, Wi-Fi security, and enterprise-scale remote access solutions with load balancing, failover, and fine-grained access-controls. Starting with the fundamental premise that complexity is the enemy of security, OpenVPN offers a cost-effective, lightweight alternative to other VPN technologies that is well-adapted for the SME and enterprise markets.\r\n\r\nSecurity Fix(es):\r\n\r\nOpenVPN from 2.6.0 through 2.6.10 in a server role accepts multiple exit notifications from authenticated clients which will extend the validity of a closing session(CVE-2024-28882)", + "cves": [ + { + "id": "CVE-2024-28882", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28882", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2024-1860": { + "id": "openEuler-SA-2024-1860", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860", + "title": "An update for kernel is now available for openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests\r\n\r\nThe FSM can run in a circle allowing rdma_resolve_ip() to be called twice\non the same id_priv. While this cannot happen without going through the\nwork, it violates the invariant that the same address resolution\nbackground request cannot be active twice.\r\n\r\n CPU 1 CPU 2\r\n\r\nrdma_resolve_addr():\n RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY\n rdma_resolve_ip(addr_handler) #1\r\n\r\n\t\t\t process_one_req(): for #1\n addr_handler():\n RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND\n mutex_unlock(&id_priv->handler_mutex);\n [.. handler still running ..]\r\n\r\nrdma_resolve_addr():\n RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY\n rdma_resolve_ip(addr_handler)\n !! two requests are now on the req_list\r\n\r\nrdma_destroy_id():\n destroy_id_handler_unlock():\n _destroy_id():\n cma_cancel_operation():\n rdma_addr_cancel()\r\n\r\n // process_one_req() self removes it\n\t\t spin_lock_bh(&lock);\n cancel_delayed_work(&req->work);\n\t if (!list_empty(&req->list)) == true\r\n\r\n ! rdma_addr_cancel() returns after process_on_req #1 is done\r\n\r\n kfree(id_priv)\r\n\r\n\t\t\t process_one_req(): for #2\n addr_handler():\n\t mutex_lock(&id_priv->handler_mutex);\n !! Use after free on id_priv\r\n\r\nrdma_addr_cancel() expects there to be one req on the list and only\ncancels the first one. The self-removal behavior of the work only happens\nafter the handler has returned. This yields a situations where the\nreq_list can have two reqs for the same \"handle\" but rdma_addr_cancel()\nonly cancels the first one.\r\n\r\nThe second req remains active beyond rdma_destroy_id() and will\nuse-after-free id_priv once it inevitably triggers.\r\n\r\nFix this by remembering if the id_priv has called rdma_resolve_ip() and\nalways cancel before calling it again. This ensures the req_list never\ngets more than one item in it and doesn't cost anything in the normal flow\nthat never uses this strange error path.(CVE-2021-47391)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Forward wakeup to smc socket waitqueue after fallback\r\n\r\nWhen we replace TCP with SMC and a fallback occurs, there may be\nsome socket waitqueue entries remaining in smc socket->wq, such\nas eppoll_entries inserted by userspace applications.\r\n\r\nAfter the fallback, data flows over TCP/IP and only clcsocket->wq\nwill be woken up. Applications can't be notified by the entries\nwhich were inserted in smc socket->wq before fallback. So we need\na mechanism to wake up smc socket->wq at the same time if some\nentries remaining in it.\r\n\r\nThe current workaround is to transfer the entries from smc socket->wq\nto clcsock->wq during the fallback. But this may cause a crash\nlike this:\r\n\r\n general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI\n CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107\n RIP: 0010:__wake_up_common+0x65/0x170\n Call Trace:\n \n __wake_up_common_lock+0x7a/0xc0\n sock_def_readable+0x3c/0x70\n tcp_data_queue+0x4a7/0xc40\n tcp_rcv_established+0x32f/0x660\n ? sk_filter_trim_cap+0xcb/0x2e0\n tcp_v4_do_rcv+0x10b/0x260\n tcp_v4_rcv+0xd2a/0xde0\n ip_protocol_deliver_rcu+0x3b/0x1d0\n ip_local_deliver_finish+0x54/0x60\n ip_local_deliver+0x6a/0x110\n ? tcp_v4_early_demux+0xa2/0x140\n ? tcp_v4_early_demux+0x10d/0x140\n ip_sublist_rcv_finish+0x49/0x60\n ip_sublist_rcv+0x19d/0x230\n ip_list_rcv+0x13e/0x170\n __netif_receive_skb_list_core+0x1c2/0x240\n netif_receive_skb_list_internal+0x1e6/0x320\n napi_complete_done+0x11d/0x190\n mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]\n __napi_poll+0x3c/0x1b0\n net_rx_action+0x27c/0x300\n __do_softirq+0x114/0x2d2\n irq_exit_rcu+0xb4/0xe0\n common_interrupt+0xba/0xe0\n \n \r\n\r\nThe crash is caused by privately transferring waitqueue entries from\nsmc socket->wq to clcsock->wq. The owners of these entries, such as\nepoll, have no idea that the entries have been transferred to a\ndifferent socket wait queue and still use original waitqueue spinlock\n(smc socket->wq.wait.lock) to make the entries operation exclusive,\nbut it doesn't work. The operations to the entries, such as removing\nfrom the waitqueue (now is clcsock->wq after fallback), may cause a\ncrash when clcsock waitqueue is being iterated over at the moment.\r\n\r\nThis patch tries to fix this by no longer transferring wait queue\nentries privately, but introducing own implementations of clcsock's\ncallback functions in fallback situation. The callback functions will\nforward the wakeup to smc socket->wq if clcsock->wq is actually woken\nup and smc socket->wq has remaining entries.(CVE-2022-48721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Do not use WQ_MEM_RECLAIM flag for workqueue\r\n\r\nWhen both ice and the irdma driver are loaded, a warning in\ncheck_flush_dependency is being triggered. This is due to ice driver\nworkqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one\nis not.\r\n\r\nAccording to kernel documentation, this flag should be set if the\nworkqueue will be involved in the kernel's memory reclamation flow.\nSince it is not, there is no need for the ice driver's WQ to have this\nflag set so remove it.\r\n\r\nExample trace:\r\n\r\n[ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0\n[ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0\n[ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha\nin_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel\n_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1\n0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_\ncore_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs\nib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter\nacpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba\nta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse\n[ +0.000161] [last unloaded: bonding]\n[ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1\n[ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020\n[ +0.000003] Workqueue: ice ice_service_task [ice]\n[ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0\n[ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08\n9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06\n[ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282\n[ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000\n[ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80\n[ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112\n[ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000\n[ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400\n[ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000\n[ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0\n[ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ +0.000002] PKRU: 55555554\n[ +0.000003] Call Trace:\n[ +0.000002] \n[ +0.000003] __flush_workqueue+0x203/0x840\n[ +0.000006] ? mutex_unlock+0x84/0xd0\n[ +0.000008] ? __pfx_mutex_unlock+0x10/0x10\n[ +0.000004] ? __pfx___flush_workqueue+0x10/0x10\n[ +0.000006] ? mutex_lock+0xa3/0xf0\n[ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core]\n[ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core]\n[ +0.000094] ib_unregister_device+0x25/0x30 [ib_core]\n[ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma]\n[ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]\n[ +0.000059] ? up_write+0x5c/0x90\n[ +0.000005] irdma_remove+0x36/0x90 [irdma]\n[ +0.000062] auxiliary_bus_remove+0x32/0x50\n[ +0.000007] device_r\n---truncated---(CVE-2023-52743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix slab out of bounds write in smb_inherit_dacl()\r\n\r\nslab out-of-bounds write is caused by that offsets is bigger than pntsd\nallocation size. This patch add the check to validate 3 offsets using\nallocation size.(CVE-2023-52755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: btusb: Add date->evt_skb is NULL check\r\n\r\nfix crash because of null pointers\r\n\r\n[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8\n[ 6104.969667] #PF: supervisor read access in kernel mode\n[ 6104.969668] #PF: error_code(0x0000) - not-present page\n[ 6104.969670] PGD 0 P4D 0\n[ 6104.969673] Oops: 0000 [#1] SMP NOPTI\n[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]\n[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246\n[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006\n[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000\n[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001\n[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0\n[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90\n[ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000\n[ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0\n[ 6104.969701] PKRU: 55555554\n[ 6104.969702] Call Trace:\n[ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb]\n[ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth]\n[ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth]\n[ 6104.969753] rfkill_set_block+0x92/0x160\n[ 6104.969755] rfkill_fop_write+0x136/0x1e0\n[ 6104.969759] __vfs_write+0x18/0x40\n[ 6104.969761] vfs_write+0xdf/0x1c0\n[ 6104.969763] ksys_write+0xb1/0xe0\n[ 6104.969765] __x64_sys_write+0x1a/0x20\n[ 6104.969769] do_syscall_64+0x51/0x180\n[ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9\n[ 6104.969773] RIP: 0033:0x7f5a21f18fef\n[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\n[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef\n[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012\n[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017\n[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002\n[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0(CVE-2023-52833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock\r\n\r\nIt needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock\nto avoid racing with checkpoint, otherwise, filesystem metadata including\nblkaddr in dnode, inode fields and .total_valid_block_count may be\ncorrupted after SPO case.(CVE-2024-34027)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnull_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'\r\n\r\nWriting 'power' and 'submit_queues' concurrently will trigger kernel\npanic:\r\n\r\nTest script:\r\n\r\nmodprobe null_blk nr_devices=0\nmkdir -p /sys/kernel/config/nullb/nullb0\nwhile true; do echo 1 > submit_queues; echo 4 > submit_queues; done &\nwhile true; do echo 1 > power; echo 0 > power; done\r\n\r\nTest result:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000148\nOops: 0000 [#1] PREEMPT SMP\nRIP: 0010:__lock_acquire+0x41d/0x28f0\nCall Trace:\n \n lock_acquire+0x121/0x450\n down_write+0x5f/0x1d0\n simple_recursive_removal+0x12f/0x5c0\n blk_mq_debugfs_unregister_hctxs+0x7c/0x100\n blk_mq_update_nr_hw_queues+0x4a3/0x720\n nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]\n nullb_device_submit_queues_store+0x79/0xf0 [null_blk]\n configfs_write_iter+0x119/0x1e0\n vfs_write+0x326/0x730\n ksys_write+0x74/0x150\r\n\r\nThis is because del_gendisk() can concurrent with\nblk_mq_update_nr_hw_queues():\r\n\r\nnullb_device_power_store\tnullb_apply_submit_queues\n null_del_dev\n del_gendisk\n\t\t\t\t nullb_update_nr_hw_queues\n\t\t\t\t if (!dev->nullb)\n\t\t\t\t // still set while gendisk is deleted\n\t\t\t\t return 0\n\t\t\t\t blk_mq_update_nr_hw_queues\n dev->nullb = NULL\r\n\r\nFix this problem by resuing the global mutex to protect\nnullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq\r\n\r\nUndefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called\nwith hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0.\nIn that case, \"roundup_pow_of_two(hwq_attr->aux_stride)\" gets called.\nroundup_pow_of_two is documented as undefined for 0.\r\n\r\nFix it in the one caller that had this combination.\r\n\r\nThe undefined behavior was detected by UBSAN:\n UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13\n shift exponent 64 is too large for 64-bit type 'long unsigned int'\n CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4\n Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023\n Call Trace:\n \n dump_stack_lvl+0x5d/0x80\n ubsan_epilogue+0x5/0x30\n __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec\n __roundup_pow_of_two+0x25/0x35 [bnxt_re]\n bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]\n bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]\n bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __kmalloc+0x1b6/0x4f0\n ? create_qp.part.0+0x128/0x1c0 [ib_core]\n ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]\n create_qp.part.0+0x128/0x1c0 [ib_core]\n ib_create_qp_kernel+0x50/0xd0 [ib_core]\n create_mad_qp+0x8e/0xe0 [ib_core]\n ? __pfx_qp_event_handler+0x10/0x10 [ib_core]\n ib_mad_init_device+0x2be/0x680 [ib_core]\n add_client_context+0x10d/0x1a0 [ib_core]\n enable_device_and_get+0xe0/0x1d0 [ib_core]\n ib_register_device+0x53c/0x630 [ib_core]\n ? srso_alias_return_thunk+0x5/0xfbef5\n bnxt_re_probe+0xbd8/0xe50 [bnxt_re]\n ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]\n auxiliary_bus_probe+0x49/0x80\n ? driver_sysfs_add+0x57/0xc0\n really_probe+0xde/0x340\n ? pm_runtime_barrier+0x54/0x90\n ? __pfx___driver_attach+0x10/0x10\n __driver_probe_device+0x78/0x110\n driver_probe_device+0x1f/0xa0\n __driver_attach+0xba/0x1c0\n bus_for_each_dev+0x8f/0xe0\n bus_add_driver+0x146/0x220\n driver_register+0x72/0xd0\n __auxiliary_driver_register+0x6e/0xd0\n ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]\n ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n do_one_initcall+0x5b/0x310\n do_init_module+0x90/0x250\n init_module_from_file+0x86/0xc0\n idempotent_init_module+0x121/0x2b0\n __x64_sys_finit_module+0x5e/0xb0\n do_syscall_64+0x82/0x160\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? syscall_exit_to_user_mode_prepare+0x149/0x170\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? syscall_exit_to_user_mode+0x75/0x230\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? do_syscall_64+0x8e/0x160\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __count_memcg_events+0x69/0x100\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? count_memcg_events.constprop.0+0x1a/0x30\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? handle_mm_fault+0x1f0/0x300\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? do_user_addr_fault+0x34e/0x640\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? srso_alias_return_thunk+0x5/0xfbef5\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f4e5132821d\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48\n RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139\n RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d\n RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b\n RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0\n R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d\n R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60\n \n ---[ end trace ]---(CVE-2024-38540)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: openvswitch: fix overwriting ct original tuple for ICMPv6\r\n\r\nOVS_PACKET_CMD_EXECUTE has 3 main attributes:\n - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.\n - OVS_PACKET_ATTR_PACKET - Binary packet content.\n - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.\r\n\r\nOVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure\nwith the metadata like conntrack state, input port, recirculation id,\netc. Then the packet itself gets parsed to populate the rest of the\nkeys from the packet headers.\r\n\r\nWhenever the packet parsing code starts parsing the ICMPv6 header, it\nfirst zeroes out fields in the key corresponding to Neighbor Discovery\ninformation even if it is not an ND packet.\r\n\r\nIt is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares\nthe space between 'nd' and 'ct_orig' that holds the original tuple\nconntrack metadata parsed from the OVS_PACKET_ATTR_KEY.\r\n\r\nND packets should not normally have conntrack state, so it's fine to\nshare the space, but normal ICMPv6 Echo packets or maybe other types of\nICMPv6 can have the state attached and it should not be overwritten.\r\n\r\nThe issue results in all but the last 4 bytes of the destination\naddress being wiped from the original conntrack tuple leading to\nincorrect packet matching and potentially executing wrong actions\nin case this packet recirculates within the datapath or goes back\nto userspace.\r\n\r\nND fields should not be accessed in non-ND packets, so not clearing\nthem should be fine. Executing memset() only for actual ND packets to\navoid the issue.\r\n\r\nInitializing the whole thing before parsing is needed because ND packet\nmay not contain all the options.\r\n\r\nThe issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't\naffect packets entering OVS datapath from network interfaces, because\nin this case CT metadata is populated from skb after the packet is\nalready parsed.(CVE-2024-38558)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: Fix potential glock use-after-free on unmount\r\n\r\nWhen a DLM lockspace is released and there ares still locks in that\nlockspace, DLM will unlock those locks automatically. Commit\nfb6791d100d1b started exploiting this behavior to speed up filesystem\nunmount: gfs2 would simply free glocks it didn't want to unlock and then\nrelease the lockspace. This didn't take the bast callbacks for\nasynchronous lock contention notifications into account, which remain\nactive until until a lock is unlocked or its lockspace is released.\r\n\r\nTo prevent those callbacks from accessing deallocated objects, put the\nglocks that should not be unlocked on the sd_dead_glocks list, release\nthe lockspace, and only then free those glocks.\r\n\r\nAs an additional measure, ignore unexpected ast and bast callbacks if\nthe receiving glock is dead.(CVE-2024-38570)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\r\n\r\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\r\n\r\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\r\n\r\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied.(CVE-2024-38586)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix resync softlockup when bitmap size is less than array size\r\n\r\nIs is reported that for dm-raid10, lvextend + lvchange --syncaction will\ntrigger following softlockup:\r\n\r\nkernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]\nCPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1\nRIP: 0010:_raw_spin_unlock_irq+0x13/0x30\nCall Trace:\n \n md_bitmap_start_sync+0x6b/0xf0\n raid10_sync_request+0x25c/0x1b40 [raid10]\n md_do_sync+0x64b/0x1020\n md_thread+0xa7/0x170\n kthread+0xcf/0x100\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1a/0x30\r\n\r\nAnd the detailed process is as follows:\r\n\r\nmd_do_sync\n j = mddev->resync_min\n while (j < max_sectors)\n sectors = raid10_sync_request(mddev, j, &skipped)\n if (!md_bitmap_start_sync(..., &sync_blocks))\n // md_bitmap_start_sync set sync_blocks to 0\n return sync_blocks + sectors_skippe;\n // sectors = 0;\n j += sectors;\n // j never change\r\n\r\nRoot cause is that commit 301867b1c168 (\"md/raid10: check\nslab-out-of-bounds in md_bitmap_get_counter\") return early from\nmd_bitmap_get_counter(), without setting returned blocks.\r\n\r\nFix this problem by always set returned blocks from\nmd_bitmap_get_counter\"(), as it used to be.\r\n\r\nNoted that this patch just fix the softlockup problem in kernel, the\ncase that bitmap size doesn't match array size still need to be fixed.(CVE-2024-38598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: core: Fix NULL module pointer assignment at card init\r\n\r\nThe commit 81033c6b584b (\"ALSA: core: Warn on empty module\")\nintroduced a WARN_ON() for a NULL module pointer passed at snd_card\nobject creation, and it also wraps the code around it with '#ifdef\nMODULE'. This works in most cases, but the devils are always in\ndetails. \"MODULE\" is defined when the target code (i.e. the sound\ncore) is built as a module; but this doesn't mean that the caller is\nalso built-in or not. Namely, when only the sound core is built-in\n(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),\nthe passed module pointer is ignored even if it's non-NULL, and\ncard->module remains as NULL. This would result in the missing module\nreference up/down at the device open/close, leading to a race with the\ncode execution after the module removal.\r\n\r\nFor addressing the bug, move the assignment of card->module again out\nof ifdef. The WARN_ON() is still wrapped with ifdef because the\nmodule can be really NULL when all sound drivers are built-in.\r\n\r\nNote that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would\nlead to a false-positive NULL module check. Admittedly it won't catch\nperfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no\nreal problem as it's only for debugging, and the condition is pretty\nrare.(CVE-2024-38605)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpufreq: exit() callback is optional\r\n\r\nThe exit() callback is optional and shouldn't be called without checking\na valid pointer first.\r\n\r\nAlso, we must clear freq_table pointer even if the exit() callback isn't\npresent.(CVE-2024-38615)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: fix potential memory leak in vfio_intx_enable()\r\n\r\nIf vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.(CVE-2024-38632)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkdb: Fix buffer overflow during tab-complete\r\n\r\nCurrently, when the user attempts symbol completion with the Tab key, kdb\nwill use strncpy() to insert the completed symbol into the command buffer.\nUnfortunately it passes the size of the source buffer rather than the\ndestination to strncpy() with predictably horrible results. Most obviously\nif the command buffer is already full but cp, the cursor position, is in\nthe middle of the buffer, then we will write past the end of the supplied\nbuffer.\r\n\r\nFix this by replacing the dubious strncpy() calls with memmove()/memcpy()\ncalls plus explicit boundary checks to make sure we have enough space\nbefore we start moving characters around.(CVE-2024-39480)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()\r\n\r\nIn function bond_option_arp_ip_targets_set(), if newval->string is an\nempty string, newval->string+1 will point to the byte after the\nstring, causing an out-of-bound read.\r\n\r\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 \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 ]---\r\n\r\nFix it by adding a check of string length before using it.(CVE-2024-39487)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY\r\n\r\nWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes\nto bug_table entries, and as a result the last entry in a bug table will\nbe ignored, potentially leading to an unexpected panic(). All prior\nentries in the table will be handled correctly.\r\n\r\nThe arm64 ABI requires that struct fields of up to 8 bytes are\nnaturally-aligned, with padding added within a struct such that struct\nare suitably aligned within arrays.\r\n\r\nWhen CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:\r\n\r\n\tstruct bug_entry {\n\t\tsigned int bug_addr_disp;\t// 4 bytes\n\t\tsigned int file_disp;\t// 4 bytes\n\t\tunsigned short line;\t\t// 2 bytes\n\t\tunsigned short flags;\t\t// 2 bytes\n\t}\r\n\r\n... with 12 bytes total, requiring 4-byte alignment.\r\n\r\nWhen CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:\r\n\r\n\tstruct bug_entry {\n\t\tsigned int bug_addr_disp;\t// 4 bytes\n\t\tunsigned short flags;\t\t// 2 bytes\n\t\t< implicit padding >\t\t// 2 bytes\n\t}\r\n\r\n... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing\npadding, requiring 4-byte alginment.\r\n\r\nWhen we create a bug_entry in assembly, we align the start of the entry\nto 4 bytes, which implicitly handles padding for any prior entries.\nHowever, we do not align the end of the entry, and so when\nCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding\nbytes.\r\n\r\nFor the main kernel image this is not a problem as find_bug() doesn't\ndepend on the trailing padding bytes when searching for entries:\r\n\r\n\tfor (bug = __start___bug_table; bug < __stop___bug_table; ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\treturn bug;\r\n\r\nHowever for modules, module_bug_finalize() depends on the trailing\nbytes when calculating the number of entries:\r\n\r\n\tmod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);\r\n\r\n... and as the last bug_entry lacks the necessary padding bytes, this entry\nwill not be counted, e.g. in the case of a single entry:\r\n\r\n\tsechdrs[i].sh_size == 6\n\tsizeof(struct bug_entry) == 8;\r\n\r\n\tsechdrs[i].sh_size / sizeof(struct bug_entry) == 0;\r\n\r\nConsequently module_find_bug() will miss the last bug_entry when it does:\r\n\r\n\tfor (i = 0; i < mod->num_bugs; ++i, ++bug)\n\t\tif (bugaddr == bug_addr(bug))\n\t\t\tgoto out;\r\n\r\n... which can lead to a kenrel panic due to an unhandled bug.\r\n\r\nThis can be demonstrated with the following module:\r\n\r\n\tstatic int __init buginit(void)\n\t{\n\t\tWARN(1, \"hello\\n\");\n\t\treturn 0;\n\t}\r\n\r\n\tstatic void __exit bugexit(void)\n\t{\n\t}\r\n\r\n\tmodule_init(buginit);\n\tmodule_exit(bugexit);\n\tMODULE_LICENSE(\"GPL\");\r\n\r\n... which will trigger a kernel panic when loaded:\r\n\r\n\t------------[ cut here ]------------\n\thello\n\tUnexpected kernel BRK exception at EL1\n\tInternal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP\n\tModules linked in: hello(O+)\n\tCPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8\n\tHardware name: linux,dummy-virt (DT)\n\tpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n\tpc : buginit+0x18/0x1000 [hello]\n\tlr : buginit+0x18/0x1000 [hello]\n\tsp : ffff800080533ae0\n\tx29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000\n\tx26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58\n\tx23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0\n\tx20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006\n\tx17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720\n\tx14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312\n\tx11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8\n\tx8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000\n\tx5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000\n\tx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0\n\tCall trace:\n\t buginit+0x18/0x1000 [hello]\n\t do_one_initcall+0x80/0x1c8\n\t do_init_module+0x60/0x218\n\t load_module+0x1ba4/0x1d70\n\t __do_sys_init_module+0x198/0x1d0\n\t __arm64_sys_init_module+0x1c/0x28\n\t invoke_syscall+0x48/0x114\n\t el0_svc\n---truncated---(CVE-2024-39488)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix memleak in seg6_hmac_init_algo\r\n\r\nseg6_hmac_init_algo returns without cleaning up the previous allocations\nif one fails, so it's going to leak all that memory and the crypto tfms.\r\n\r\nUpdate seg6_hmac_exit to only free the memory when allocated, so we can\nreuse the code directly.(CVE-2024-39489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsock_map: avoid race between sock_map_close and sk_psock_put\r\n\r\nsk_psock_get will return NULL if the refcount of psock has gone to 0, which\nwill happen when the last call of sk_psock_put is done. However,\nsk_psock_drop may not have finished yet, so the close callback will still\npoint to sock_map_close despite psock being NULL.\r\n\r\nThis can be reproduced with a thread deleting an element from the sock map,\nwhile the second one creates a socket, adds it to the map and closes it.\r\n\r\nThat will trigger the WARN_ON_ONCE:\r\n\r\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nModules linked in:\nCPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nCode: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02\nRSP: 0018:ffffc9000441fda8 EFLAGS: 00010293\nRAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000\nRDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0\nRBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3\nR10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840\nR13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870\nFS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0\nCall Trace:\n \n unix_release+0x87/0xc0 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0xbe/0x240 net/socket.c:1421\n __fput+0x42b/0x8a0 fs/file_table.c:422\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close fs/open.c:1541 [inline]\n __x64_sys_close+0x7f/0x110 fs/open.c:1541\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fb37d618070\nCode: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c\nRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003\nRAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070\nRDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n \r\n\r\nUse sk_psock, which will only check that the pointer is not been set to\nNULL yet, which should only happen after the callbacks are restored. If,\nthen, a reference can still be gotten, we may call sk_psock_stop and cancel\npsock->work.\r\n\r\nAs suggested by Paolo Abeni, reorder the condition so the control flow is\nless convoluted.\r\n\r\nAfter that change, the reproducer does not trigger the WARN_ON_ONCE\nanymore.(CVE-2024-39500)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: ensure snd_una is properly initialized on connect\r\n\r\nThis is strictly related to commit fb7a0d334894 (\"mptcp: ensure snd_nxt\nis properly initialized on connect\"). It turns out that syzkaller can\ntrigger the retransmit after fallback and before processing any other\nincoming packet - so that snd_una is still left uninitialized.\r\n\r\nAddress the issue explicitly initializing snd_una together with snd_nxt\nand write_seq.(CVE-2024-40931)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: remove clear SB_INLINECRYPT flag in default_options\r\n\r\nIn f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.\nIf create new file or open file during this gap, these files\nwill not use inlinecrypt. Worse case, it may lead to data\ncorruption if wrappedkey_v0 is enable.\r\n\r\nThread A: Thread B:\r\n\r\n-f2fs_remount\t\t\t\t-f2fs_file_open or f2fs_new_inode\n -default_options\n\t<- clear SB_INLINECRYPT flag\r\n\r\n -fscrypt_select_encryption_impl\r\n\r\n -parse_options\n\t<- set SB_INLINECRYPT again(CVE-2024-40971)", + "cves": [ + { + "id": "CVE-2024-40971", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40971", + "severity": "Low" + } + ] + }, + "openEuler-SA-2022-1670": { + "id": "openEuler-SA-2022-1670", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1670", + "title": "An update for ImageMagick is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3 and openEuler-22.03-LTS", + "severity": "High", + "description": "Use ImageMagick to create, edit, compose, or convert bitmap images. It can read and write images in a variety of formats (over 200) including PNG, JPEG, GIF, HEIC, TIFF, DPX, EXR, WebP, Postscript, PDF, and SVG. Use ImageMagick to resize, flip, mirror, rotate, distort, shear and transform images, adjust image colors, apply various special effects, or draw text, lines, polygons, ellipses and Bézier curves.\n\nSecurity Fix(es):\n\nA heap-use-after-free flaw was found in ImageMagick's RelinquishDCMInfo() function of dcm.c file. This vulnerability is triggered when an attacker passes a specially crafted DICOM image file to ImageMagick for conversion, potentially leading to information disclosure and a denial of service.(CVE-2022-1114)", + "cves": [ + { + "id": "CVE-2022-1114", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1114", + "severity": "High" + } + ] + }, + "openEuler-SA-2024-1600": { + "id": "openEuler-SA-2024-1600", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1600", + "title": "An update for xorg-x11-server-xwayland is now available for openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "Xwayland is an X server for running X clients under Wayland. %package devel Summary: Development package Requires: pkgconfig %description devel The development package provides the developmental files which are necessary for developing Wayland compositors using Xwayland. %prep %autosetup -n xwayland- %build %meson \\ -Dxwayland_eglstream=true \\ -Ddefault_font_path=\"catalogue:/etc/X11/fontpath.d,built-ins\" \\ -Dbuilder_string=\"Build ID: -\" \\ -Dxkb_output_dir=/lib/xkb \\ -Dxcsecurity=true \\ -Dglamor=true \\ -Ddri3=true %meson_build\r\n\r\nSecurity Fix(es):\r\n\r\nAn out-of-bounds memory access flaw was found in the X.Org server. This issue can be triggered when a device frozen by a sync grab is reattached to a different master device. This issue may lead to an application crash, local privilege escalation (if the server runs with extended privileges), or remote code execution in SSH X11 forwarding environments.(CVE-2024-0229)\r\n\r\nA flaw was found in the X.Org server. The cursor code in both Xephyr and Xwayland uses the wrong type of private at creation. It uses the cursor bits type with the cursor as private, and when initiating the cursor, that overwrites the XSELINUX context.(CVE-2024-0409)", + "cves": [ + { + "id": "CVE-2024-0409", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0409", + "severity": "High" + } + ] + }, + "openEuler-SA-2024-1467": { + "id": "openEuler-SA-2024-1467", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1467", + "title": "An update for docker is now available for openEuler-22.03-LTS-SP2", + "severity": "Medium", + "description": "Docker is an open source project to build, ship and run any application as a lightweight container.\r\n\r\nSecurity Fix(es):\r\n\r\nMoby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. Moby's networking implementation allows for many networks, each with their own IP address range and gateway, to be defined. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well.\r\n\r\nWhen containers with networking are created, they are assigned unique network interfaces and IP addresses. The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.\r\n\r\nContainers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.\r\n\r\nIn addition to configuring the Linux kernel's various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery, and resolution of names from an upstream resolver.\r\n\r\nWhen a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver. This request is made from the container's network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.\r\n\r\nAs a consequence of this design, containers solely attached to an internal network will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.\r\n\r\nMany systems run a local forwarding DNS resolver. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the host namework namespace. The loopback resolver then forwards the requests to its configured upstream resolvers, as expected.\r\n\r\nBecause `dockerd` forwards DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers.\r\n\r\nDocker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.\r\n\r\nMoby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal networks. As a workaround, run containers intended to be solely attached to internal networks with a custom upstream address, which will force all upstream DNS queries to be resolved from the container's network namespace.(CVE-2024-29018)", + "cves": [ + { + "id": "CVE-2024-29018", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29018", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2024-1501": { + "id": "openEuler-SA-2024-1501", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1501", + "title": "An update for kernel is now available for openEuler-22.03-LTS-SP3", + "severity": "High", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix out of bounds in init_smb2_rsp_hdr()\r\n\r\nIf client send smb2 negotiate request and then send smb1 negotiate\nrequest, init_smb2_rsp_hdr is called for smb1 negotiate request since\nneed_neg is set to false. This patch ignore smb1 packets after ->need_neg\nis set to false.(CVE-2023-52441)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: Don't unref the same fb many times by mistake due to deadlock handling\r\n\r\nIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()\nwe proceed to unref the fb and then retry the whole thing from the top.\nBut we forget to reset the fb pointer back to NULL, and so if we then\nget another error during the retry, before the fb lookup, we proceed\nthe unref the same fb again without having gotten another reference.\nThe end result is that the fb will (eventually) end up being freed\nwhile it's still in use.\r\n\r\nReset fb to NULL once we've unreffed it to avoid doing it again\nuntil we've done another fb lookup.\r\n\r\nThis turned out to be pretty easy to hit on a DG2 when doing async\nflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I\nsaw that drm_closefb() simply got stuck in a busy loop while walking\nthe framebuffer list. Fortunately I was able to convince it to oops\ninstead, and from there it was easier to track down the culprit.(CVE-2023-52486)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run\r\n\r\nIn mtk_jpeg_probe, &jpeg->job_timeout_work is bound with\nmtk_jpeg_job_timeout_work.\r\n\r\nIn mtk_jpeg_dec_device_run, if error happens in\nmtk_jpeg_set_dec_dst, it will finally start the worker while\nmark the job as finished by invoking v4l2_m2m_job_finish.\r\n\r\nThere are two methods to trigger the bug. If we remove the\nmodule, it which will call mtk_jpeg_remove to make cleanup.\nThe possible sequence is as follows, which will cause a\nuse-after-free bug.\r\n\r\nCPU0 CPU1\nmtk_jpeg_dec_... |\n start worker\t |\n |mtk_jpeg_job_timeout_work\nmtk_jpeg_remove |\n v4l2_m2m_release |\n kfree(m2m_dev); |\n |\n | v4l2_m2m_get_curr_priv\n | m2m_dev->curr_ctx //use\r\n\r\nIf we close the file descriptor, which will call mtk_jpeg_release,\nit will have a similar sequence.\r\n\r\nFix this bug by starting timeout worker only if started jpegdec worker\nsuccessfully. Then v4l2_m2m_job_finish will only be called in\neither mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.(CVE-2023-52491)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: fix NULL pointer in channel unregistration function\r\n\r\n__dma_async_device_channel_register() can fail. In case of failure,\nchan->local is freed (with free_percpu()), and chan->local is nullified.\nWhen dma_async_device_unregister() is called (because of managed API or\nintentionally by DMA controller driver), channels are unconditionally\nunregistered, leading to this NULL pointer:\n[ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\n[...]\n[ 1.484499] Call trace:\n[ 1.486930] device_del+0x40/0x394\n[ 1.490314] device_unregister+0x20/0x7c\n[ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0\r\n\r\nLook at dma_async_device_register() function error path, channel device\nunregistration is done only if chan->local is not NULL.\r\n\r\nThen add the same condition at the beginning of\n__dma_async_device_channel_unregister() function, to avoid NULL pointer\nissue whatever the API used to reach this function.(CVE-2023-52492)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbus: mhi: host: Drop chan lock before queuing buffers\r\n\r\nEnsure read and write locks for the channel are not taken in succession by\ndropping the read lock from parse_xfer_event() such that a callback given\nto client can potentially queue buffers and acquire the write lock in that\nprocess. Any queueing of buffers should be done without channel read lock\nacquired as it can result in multiple locks and a soft lockup.\r\n\r\n[mani: added fixes tag and cc'ed stable](CVE-2023-52493)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbus: mhi: host: Add alignment check for event ring read pointer\r\n\r\nThough we do check the event ring read pointer by \"is_valid_ring_ptr\"\nto make sure it is in the buffer range, but there is another risk the\npointer may be not aligned. Since we are expecting event ring elements\nare 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer\ncould lead to multiple issues like DoS or ring buffer memory corruption.\r\n\r\nSo add a alignment check for event ring read pointer.(CVE-2023-52494)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPM: sleep: Fix possible deadlocks in core system-wide PM code\r\n\r\nIt is reported that in low-memory situations the system-wide resume core\ncode deadlocks, because async_schedule_dev() executes its argument\nfunction synchronously if it cannot allocate memory (and not only in\nthat case) and that function attempts to acquire a mutex that is already\nheld. Executing the argument function synchronously from within\ndpm_async_fn() may also be problematic for ordering reasons (it may\ncause a consumer device's resume callback to be invoked before a\nrequisite supplier device's one, for example).\r\n\r\nAddress this by changing the code in question to use\nasync_schedule_dev_nocall() for scheduling the asynchronous\nexecution of device suspend and resume functions and to directly\nrun them synchronously if async_schedule_dev_nocall() returns false.(CVE-2023-52498)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntee: amdtee: fix use-after-free vulnerability in amdtee_close_session\r\n\r\nThere is a potential race condition in amdtee_close_session that may\ncause use-after-free in amdtee_open_session. For instance, if a session\nhas refcount == 1, and one thread tries to free this session via:\r\n\r\n kref_put(&sess->refcount, destroy_session);\r\n\r\nthe reference count will get decremented, and the next step would be to\ncall destroy_session(). However, if in another thread,\namdtee_open_session() is called before destroy_session() has completed\nexecution, alloc_session() may return 'sess' that will be freed up\nlater in destroy_session() leading to use-after-free in\namdtee_open_session.\r\n\r\nTo fix this issue, treat decrement of sess->refcount and removal of\n'sess' from session list in destroy_session() as a critical section, so\nthat it is executed atomically.(CVE-2023-52503)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/alternatives: Disable KASAN in apply_alternatives()\r\n\r\nFei has reported that KASAN triggers during apply_alternatives() on\na 5-level paging machine:\r\n\r\n\tBUG: KASAN: out-of-bounds in rcu_is_watching()\n\tRead of size 4 at addr ff110003ee6419a0 by task swapper/0/0\n\t...\n\t__asan_load4()\n\trcu_is_watching()\n\ttrace_hardirqs_on()\n\ttext_poke_early()\n\tapply_alternatives()\n\t...\r\n\r\nOn machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)\ngets patched. It includes KASAN code, where KASAN_SHADOW_START depends on\n__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().\r\n\r\nKASAN gets confused when apply_alternatives() patches the\nKASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START\nstatic, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.\r\n\r\nFix it for real by disabling KASAN while the kernel is patching alternatives.\r\n\r\n[ mingo: updated the changelog ](CVE-2023-52504)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nfc: llcp: Add lock when modifying device list\r\n\r\nThe device list needs its associated lock held when modifying it, or the\nlist could become corrupted, as syzbot discovered.(CVE-2023-52524)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: 8250_port: Check IRQ data before use\r\n\r\nIn case the leaf driver wants to use IRQ polling (irq = 0) and\nIIR register shows that an interrupt happened in the 8250 hardware\nthe IRQ data can be NULL. In such a case we need to skip the wake\nevent as we came to this path from the timer interrupt and quite\nlikely system is already awake.\r\n\r\nWithout this fix we have got an Oops:\r\n\r\n serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A\n ...\n BUG: kernel NULL pointer dereference, address: 0000000000000010\n RIP: 0010:serial8250_handle_irq+0x7c/0x240\n Call Trace:\n ? serial8250_handle_irq+0x7c/0x240\n ? __pfx_serial8250_timeout+0x10/0x10(CVE-2023-52567)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nteam: fix null-ptr-deref when team device type is changed\r\n\r\nGet a null-ptr-deref bug as follows with reproducer [1].\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000228\n...\nRIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]\n...\nCall Trace:\n \n ? __die+0x24/0x70\n ? page_fault_oops+0x82/0x150\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x26/0x30\n ? vlan_dev_hard_header+0x35/0x140 [8021q]\n ? vlan_dev_hard_header+0x8e/0x140 [8021q]\n neigh_connected_output+0xb2/0x100\n ip6_finish_output2+0x1cb/0x520\n ? nf_hook_slow+0x43/0xc0\n ? ip6_mtu+0x46/0x80\n ip6_finish_output+0x2a/0xb0\n mld_sendpack+0x18f/0x250\n mld_ifc_work+0x39/0x160\n process_one_work+0x1e6/0x3f0\n worker_thread+0x4d/0x2f0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xe5/0x120\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\r\n\r\n[1]\n$ teamd -t team0 -d -c '{\"runner\": {\"name\": \"loadbalance\"}}'\n$ ip link add name t-dummy type dummy\n$ ip link add link t-dummy name t-dummy.100 type vlan id 100\n$ ip link add name t-nlmon type nlmon\n$ ip link set t-nlmon master team0\n$ ip link set t-nlmon nomaster\n$ ip link set t-dummy up\n$ ip link set team0 up\n$ ip link set t-dummy.100 down\n$ ip link set t-dummy.100 master team0\r\n\r\nWhen enslave a vlan device to team device and team device type is changed\nfrom non-ether to ether, header_ops of team device is changed to\nvlan_header_ops. That is incorrect and will trigger null-ptr-deref\nfor vlan->real_dev in vlan_dev_hard_header() because team device is not\na vlan device.\r\n\r\nCache eth_header_ops in team_setup(), then assign cached header_ops to\nheader_ops of team net device when its type is changed from non-ether\nto ether to fix the bug.(CVE-2023-52574)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52575)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/mm: Fix null-pointer dereference in pgtable_cache_add\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.(CVE-2023-52607)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: arm_scmi: Check mailbox/SMT channel for consistency\r\n\r\nOn reception of a completion interrupt the shared memory area is accessed\nto retrieve the message header at first and then, if the message sequence\nnumber identifies a transaction which is still pending, the related\npayload is fetched too.\r\n\r\nWhen an SCMI command times out the channel ownership remains with the\nplatform until eventually a late reply is received and, as a consequence,\nany further transmission attempt remains pending, waiting for the channel\nto be relinquished by the platform.\r\n\r\nOnce that late reply is received the channel ownership is given back\nto the agent and any pending request is then allowed to proceed and\noverwrite the SMT area of the just delivered late reply; then the wait\nfor the reply to the new request starts.\r\n\r\nIt has been observed that the spurious IRQ related to the late reply can\nbe wrongly associated with the freshly enqueued request: when that happens\nthe SCMI stack in-flight lookup procedure is fooled by the fact that the\nmessage header now present in the SMT area is related to the new pending\ntransaction, even though the real reply has still to arrive.\r\n\r\nThis race-condition on the A2P channel can be detected by looking at the\nchannel status bits: a genuine reply from the platform will have set the\nchannel free bit before triggering the completion IRQ.\r\n\r\nAdd a consistency check to validate such condition in the A2P ISR.(CVE-2023-52608)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: switchtec: Fix stdev_release() crash after surprise hot remove\r\n\r\nA PCI device hot removal may occur while stdev->cdev is held open. The call\nto stdev_release() then happens during close or exit, at a point way past\nswitchtec_pci_remove(). Otherwise the last ref would vanish with the\ntrailing put_device(), just before return.\r\n\r\nAt that later point in time, the devm cleanup has already removed the\nstdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted\none. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause\na fatal page fault, and the subsequent dma_free_coherent(), if reached,\nwould pass a stale &stdev->pdev->dev pointer.\r\n\r\nFix by moving MRPC DMA shutdown into switchtec_pci_remove(), after\nstdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent\nfuture accidents.\r\n\r\nReproducible via the script at\nhttps://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com(CVE-2023-52617)\r\n\r\nA null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.(CVE-2023-7042)\r\n\r\nA race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.\r\n\r\n\r\n\r\n\n(CVE-2024-24861)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix global oob in ksmbd_nl_policy\r\n\r\nSimilar to a reported issue (check the commit b33fb5b801c6 (\"net:\nqualcomm: rmnet: fix global oob in rmnet_policy\"), my local fuzzer finds\nanother global out-of-bounds read for policy ksmbd_nl_policy. See bug\ntrace below:\r\n\r\n==================================================================\nBUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]\nBUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600\nRead of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810\r\n\r\nCPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n \n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:284 [inline]\n print_report+0x172/0x475 mm/kasan/report.c:395\n kasan_report+0xbb/0x1c0 mm/kasan/report.c:495\n validate_nla lib/nlattr.c:386 [inline]\n __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600\n __nla_parse+0x3e/0x50 lib/nlattr.c:697\n __nlmsg_parse include/net/netlink.h:748 [inline]\n genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565\n genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734\n genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]\n genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850\n netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540\n genl_rcv+0x24/0x40 net/netlink/genetlink.c:861\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg+0x154/0x190 net/socket.c:734\n ____sys_sendmsg+0x6df/0x840 net/socket.c:2482\n ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536\n __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7fdd66a8f359\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359\nRDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003\nRBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000\n \r\n\r\nThe buggy address belongs to the variable:\n ksmbd_nl_policy+0x100/0xa80\r\n\r\nThe buggy address belongs to the physical page:\npage:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b\nflags: 0x200000000001000(reserved|node=0|zone=2)\nraw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000\nraw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\r\n\r\nMemory state around the buggy address:\n ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n>ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9\n ^\n ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05\n ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9\n==================================================================\r\n\r\nTo fix it, add a placeholder named __KSMBD_EVENT_MAX and let\nKSMBD_EVENT_MAX to be its original value - 1 according to what other\nnetlink families do. Also change two sites that refer the\nKSMBD_EVENT_MAX to correct value.(CVE-2024-26608)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: fix illegal rmb_desc access in SMC-D connection dump\r\n\r\nA crash was found when dumping SMC-D connections. It can be reproduced\nby following steps:\r\n\r\n- run nginx/wrk test:\n smc_run nginx\n smc_run wrk -t 16 -c 1000 -d -H 'Connection: Close' \r\n\r\n- continuously dump SMC-D connections in parallel:\n watch -n 1 'smcss -D'\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000030\n CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G\tE 6.7.0+ #55\n RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]\n Call Trace:\n \n ? __die+0x24/0x70\n ? page_fault_oops+0x66/0x150\n ? exc_page_fault+0x69/0x140\n ? asm_exc_page_fault+0x26/0x30\n ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]\n ? __kmalloc_node_track_caller+0x35d/0x430\n ? __alloc_skb+0x77/0x170\n smc_diag_dump_proto+0xd0/0xf0 [smc_diag]\n smc_diag_dump+0x26/0x60 [smc_diag]\n netlink_dump+0x19f/0x320\n __netlink_dump_start+0x1dc/0x300\n smc_diag_handler_dump+0x6a/0x80 [smc_diag]\n ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]\n sock_diag_rcv_msg+0x121/0x140\n ? __pfx_sock_diag_rcv_msg+0x10/0x10\n netlink_rcv_skb+0x5a/0x110\n sock_diag_rcv+0x28/0x40\n netlink_unicast+0x22a/0x330\n netlink_sendmsg+0x1f8/0x420\n __sock_sendmsg+0xb0/0xc0\n ____sys_sendmsg+0x24e/0x300\n ? copy_msghdr_from_user+0x62/0x80\n ___sys_sendmsg+0x7c/0xd0\n ? __do_fault+0x34/0x160\n ? do_read_fault+0x5f/0x100\n ? do_fault+0xb0/0x110\n ? __handle_mm_fault+0x2b0/0x6c0\n __sys_sendmsg+0x4d/0x80\n do_syscall_64+0x69/0x180\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nIt is possible that the connection is in process of being established\nwhen we dump it. Assumed that the connection has been registered in a\nlink group by smc_conn_create() but the rmb_desc has not yet been\ninitialized by smc_buf_create(), thus causing the illegal access to\nconn->rmb_desc. So fix it by checking before dump.(CVE-2024-26615)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: sh: aica: reorder cleanup operations to avoid UAF bugs\r\n\r\nThe dreamcastcard->timer could schedule the spu_dma_work and the\nspu_dma_work could also arm the dreamcastcard->timer.\r\n\r\nWhen the snd_pcm_substream is closing, the aica_channel will be\ndeallocated. But it could still be dereferenced in the worker\nthread. The reason is that del_timer() will return directly\nregardless of whether the timer handler is running or not and\nthe worker could be rescheduled in the timer handler. As a result,\nthe UAF bug will happen. The racy situation is shown below:\r\n\r\n (Thread 1) | (Thread 2)\nsnd_aicapcm_pcm_close() |\n ... | run_spu_dma() //worker\n | mod_timer()\n flush_work() |\n del_timer() | aica_period_elapsed() //timer\n kfree(dreamcastcard->channel) | schedule_work()\n | run_spu_dma() //worker\n ... | dreamcastcard->channel-> //USE\r\n\r\nIn order to mitigate this bug and other possible corner cases,\ncall mod_timer() conditionally in run_spu_dma(), then implement\nPCM sync_stop op to cancel both the timer and worker. The sync_stop\nop will be called from PCM core appropriately when needed.(CVE-2024-26654)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix use-after-free bug\r\n\r\nThe bug can be triggered by sending a single amdgpu_gem_userptr_ioctl\nto the AMDGPU DRM driver on any ASICs with an invalid address and size.\nThe bug was reported by Joonkyo Jung .\nFor example the following code:\r\n\r\nstatic void Syzkaller1(int fd)\n{\n\tstruct drm_amdgpu_gem_userptr arg;\n\tint ret;\r\n\r\n\targ.addr = 0xffffffffffff0000;\n\targ.size = 0x80000000; /*2 Gb*/\n\targ.flags = 0x7;\n\tret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg);\n}\r\n\r\nDue to the address and size are not valid there is a failure in\namdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert->\ncheck_shl_overflow, but we even the amdgpu_hmm_register failure we still call\namdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address.\nThe following stack is below when the issue is reproduced when Kazan is enabled:\r\n\r\n[ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020\n[ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340\n[ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80\n[ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246\n[ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b\n[ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260\n[ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25\n[ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00\n[ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260\n[ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000\n[ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0\n[ +0.000010] Call Trace:\n[ +0.000006] \n[ +0.000007] ? show_regs+0x6a/0x80\n[ +0.000018] ? __warn+0xa5/0x1b0\n[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340\n[ +0.000018] ? report_bug+0x24a/0x290\n[ +0.000022] ? handle_bug+0x46/0x90\n[ +0.000015] ? exc_invalid_op+0x19/0x50\n[ +0.000016] ? asm_exc_invalid_op+0x1b/0x20\n[ +0.000017] ? kasan_save_stack+0x26/0x50\n[ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340\n[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340\n[ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340\n[ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10\n[ +0.000017] ? kasan_save_alloc_info+0x1e/0x30\n[ +0.000018] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? __kasan_kmalloc+0xb1/0xc0\n[ +0.000018] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? __kasan_check_read+0x11/0x20\n[ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu]\n[ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu]\n[ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]\n[ +0.004291] ? do_syscall_64+0x5f/0xe0\n[ +0.000023] ? srso_return_thunk+0x5/0x5f\n[ +0.000017] drm_gem_object_free+0x3b/0x50 [drm]\n[ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]\n[ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]\n[ +0.004270] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? __this_cpu_preempt_check+0x13/0x20\n[ +0.000015] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0\n[ +0.000020] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20\n[ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm]\n[ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]\n[ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm]\n[ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm]\n[ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]\n[ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d\n---truncated---(CVE-2024-26656)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix hang in nilfs_lookup_dirty_data_buffers()\r\n\r\nSyzbot reported a hang issue in migrate_pages_batch() called by mbind()\nand nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.\r\n\r\nWhile migrate_pages_batch() locks a folio and waits for the writeback to\ncomplete, the log writer thread that should bring the writeback to\ncompletion picks up the folio being written back in\nnilfs_lookup_dirty_data_buffers() that it calls for subsequent log\ncreation and was trying to lock the folio. Thus causing a deadlock.\r\n\r\nIn the first place, it is unexpected that folios/pages in the middle of\nwriteback will be updated and become dirty. Nilfs2 adds a checksum to\nverify the validity of the log being written and uses it for recovery at\nmount, so data changes during writeback are suppressed. Since this is\nbroken, an unclean shutdown could potentially cause recovery to fail.\r\n\r\nInvestigation revealed that the root cause is that the wait for writeback\ncompletion in nilfs_page_mkwrite() is conditional, and if the backing\ndevice does not require stable writes, data may be modified without\nwaiting.\r\n\r\nFix these issues by making nilfs_page_mkwrite() wait for writeback to\nfinish regardless of the stable write requirement of the backing device.(CVE-2024-26696)", + "cves": [ + { + "id": "CVE-2024-26696", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26696", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-1915": { + "id": "openEuler-SA-2022-1915", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-1915", + "title": "An update for libjpeg-turbo is now available for openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2, NEON, AltiVec) to accelerate baseline JPEG compression and decompression on x86, x86-64, and ARM systems.\r\n\r\nSecurity Fix(es):\r\n\r\nA crafted input file could cause a null pointer dereference in jcopy_sample_rows() when processed by libjpeg-turbo.(CVE-2020-35538)", + "cves": [ + { + "id": "CVE-2020-35538", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35538", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1531": { + "id": "openEuler-SA-2023-1531", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1531", + "title": "An update for golang is now available for openEuler-22.03-LTS-SP2", + "severity": "Medium", + "description": "The Go Programming Language.\n\nSecurity Fix(es):\n\nExtremely large RSA keys in certificate chains can cause a client/server to expend significant CPU time verifying signatures. With fix, the size of RSA keys transmitted during handshakes is restricted to <= 8192 bits. Based on a survey of publicly trusted RSA keys, there are currently only three certificates in circulation with keys larger than this, and all three appear to be test certificates that are not actively deployed. It is possible there are larger keys in use in private PKIs, but we target the web PKI, so causing breakage here in the interests of increasing the default safety of users of crypto/tls seems reasonable.(CVE-2023-29409)", + "cves": [ + { + "id": "CVE-2023-29409", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29409", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1322": { + "id": "openEuler-SA-2023-1322", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1322", + "title": "An update for wireshark is now available for openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "Wireshark allows you to examine protocol data stored in files or as it is captured from wired or wireless (WiFi or Bluetooth) networks, USB devices,and many other sources. It supports dozens of protocol capture file formats and understands more than a thousand protocols.It has many powerful features including a rich display filter language and the ability to reassemble multiple protocol packets in order to, for example, view a complete TCP stream, save the contents of a file which was transferred over HTTP or CIFS, or play back an RTP audio stream.\r\n\r\nSecurity Fix(es):\r\n\r\nBLF file parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file(CVE-2023-2857)\r\n\r\nNetScaler file parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file(CVE-2023-2858)\r\n\r\nCandump log parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file(CVE-2023-2855)\r\n\r\nA flaw was found in the IEEE C37.118 Synchrophasor dissector of Wireshark. This issue occurs when decoding malformed packets from a pcap file or from the network, causing a buffer overflow, resulting in a denial of service.(CVE-2023-0668)\r\n\r\nVMS TCPIPtrace file parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file(CVE-2023-2856)\r\n\r\nGDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file(CVE-2023-2879)", + "cves": [ + { + "id": "CVE-2023-2879", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2879", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-2078": { + "id": "openEuler-SA-2022-2078", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-2078", + "title": "An update for wireshark is now available for openEuler-22.03-LTS", + "severity": "Critical", + "description": "Wireshark allows you to examine protocol data stored in files or as it is captured from wired or wireless (WiFi or Bluetooth) networks, USB devices, and many other sources. It supports dozens of protocol capture file formats and understands more than a thousand protocols.\r\n\r\nSecurity Fix(es):\r\n\r\nCrash in the PVFS protocol dissector in Wireshark 3.6.0 to 3.6.1 and 3.4.0 to 3.4.11 allows denial of service via packet injection or crafted capture file(CVE-2022-0583)\r\n\r\nLarge loops in multiple protocol dissectors in Wireshark 3.6.0 to 3.6.1 and 3.4.0 to 3.4.11 allow denial of service via packet injection or crafted capture file(CVE-2022-0585)\r\n\r\nCrash in the CMS protocol dissector in Wireshark 3.6.0 to 3.6.1 and 3.4.0 to 3.4.11 allows denial of service via packet injection or crafted capture file(CVE-2022-0581)\r\n\r\nInfinite loop in RTMPT protocol dissector in Wireshark 3.6.0 to 3.6.1 and 3.4.0 to 3.4.11 allows denial of service via packet injection or crafted capture file(CVE-2022-0586)\r\n\r\nUnaligned access in the CSN.1 protocol dissector in Wireshark 3.6.0 to 3.6.1 and 3.4.0 to 3.4.11 allows denial of service via packet injection or crafted capture file(CVE-2022-0582)\r\n\r\nCrash in the OPUS protocol dissector in Wireshark 3.6.0 to 3.6.8 allows denial of service via packet injection or crafted capture file(CVE-2022-3725)", + "cves": [ + { + "id": "CVE-2022-3725", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3725", + "severity": "High" + } + ] + }, + "openEuler-SA-2022-2071": { + "id": "openEuler-SA-2022-2071", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2022-2071", + "title": "An update for kernel is now available for openEuler-22.03-LTS", + "severity": "Medium", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nA vulnerability classified as problematic was found in Linux Kernel. This vulnerability affects the function bnx2x_tpa_stop of the file drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c of the component BPF. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. VDB-211042 is the identifier assigned to this vulnerability.(CVE-2022-3542)\r\n\r\nA vulnerability was found in Linux Kernel. It has been classified as problematic. This affects the function find_prog_by_sec_insn of the file tools/lib/bpf/libbpf.c of the component BPF. The manipulation leads to null pointer dereference. It is recommended to apply a patch to fix this issue. The identifier VDB-211749 was assigned to this vulnerability.(CVE-2022-3606)\n\ndrivers/scsi/stex.c in the Linux kernel through 5.19.9 allows local users to obtain sensitive information from kernel memory because stex_queuecommand_lck lacks a memset for the PASSTHRU_CMD case.(CVE-2022-40768)", + "cves": [ + { + "id": "CVE-2022-40768", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40768", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1047": { + "id": "openEuler-SA-2023-1047", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1047", + "title": "An update for libtiff is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS and openEuler-22.03-LTS-SP1", + "severity": "High", + "description": "This provides support for the Tag Image File Format (TIFF), a widely used format for storing image data. The latest version of the TIFF specification is available on-line in several different formats.And contains command-line programs for manipulating TIFF format image files using the libtiff library.\r\n\r\nSecurity Fix(es):\r\n\r\nprocessCropSelections in tools/tiffcrop.c in LibTIFF through 4.5.0 has a heap-based buffer overflow (e.g., \"WRITE of size 307203\") via a crafted TIFF image.(CVE-2022-48281)", + "cves": [ + { + "id": "CVE-2022-48281", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48281", + "severity": "High" + } + ] + }, + "openEuler-SA-2023-1085": { + "id": "openEuler-SA-2023-1085", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1085", + "title": "An update for python-cryptography is now available for openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.\r\n\r\nSecurity Fix(es):\r\n\r\ncryptography is a package designed to expose cryptographic primitives and recipes to Python developers. In affected versions `Cipher.update_into` would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as `bytes`) to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This now correctly raises an exception. This issue has been present since `update_into` was originally introduced in cryptography 1.8.(CVE-2023-23931)", + "cves": [ + { + "id": "CVE-2023-23931", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23931", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2021-1013": { + "id": "openEuler-SA-2021-1013", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2021-1013", + "title": "An update for glibc is now available for openEuler-20.03-LTS and openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "The GNU C Library project provides the core libraries for the GNU system and GNU/Linux systems, as well as many other systems that use Linux as the kernel. These libraries provide critical APIs including ISO C11, POSIX.1-2008, BSD, OS-specific APIs and more. These APIs include such foundational facilities as open, read, write, malloc, printf, getaddrinfo, dlopen, pthread_create, crypt, login, exit and more.\\r\\n\\r\\n\r\nSecurity Fix(es):\\r\\n\\r\\n\r\nThe iconv feature in the GNU C Library (aka glibc or libc6) through 2.32, when processing invalid multi-byte input sequences in the EUC-KR encoding, may have a buffer over-read.(CVE-2019-25013)\\r\\n\\r\\n", + "cves": [ + { + "id": "CVE-2019-25013", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25013", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2024-1526": { + "id": "openEuler-SA-2024-1526", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1526", + "title": "An update for kernel is now available for openEuler-20.03-LTS-SP4", + "severity": "High", + "description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: caif: fix memory leak in cfusbl_device_notify\r\n\r\nIn case of caif_enroll_dev() fail, allocated\nlink_support won't be assigned to the corresponding\nstructure. So simply free allocated pointer in case\nof error.(CVE-2021-47121)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fujitsu: fix potential null-ptr-deref\r\n\r\nIn fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer\nderef. To fix this, check the return value of ioremap and return -1\nto the caller in case of failure.(CVE-2021-47149)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix link down processing to address NULL pointer dereference\r\n\r\nIf an FC link down transition while PLOGIs are outstanding to fabric well\nknown addresses, outstanding ABTS requests may result in a NULL pointer\ndereference. Driver unload requests may hang with repeated \"2878\" log\nmessages.\r\n\r\nThe Link down processing results in ABTS requests for outstanding ELS\nrequests. The Abort WQEs are sent for the ELSs before the driver had set\nthe link state to down. Thus the driver is sending the Abort with the\nexpectation that an ABTS will be sent on the wire. The Abort request is\nstalled waiting for the link to come up. In some conditions the driver may\nauto-complete the ELSs thus if the link does come up, the Abort completions\nmay reference an invalid structure.\r\n\r\nFix by ensuring that Abort set the flag to avoid link traffic if issued due\nto conditions where the link failed.(CVE-2021-47183)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncfg80211: call cfg80211_stop_ap when switch from P2P_GO type\r\n\r\nIf the userspace tools switch from NL80211_IFTYPE_P2P_GO to\nNL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it\ndoes not call the cleanup cfg80211_stop_ap(), this leads to the\ninitialization of in-use data. For example, this path re-init the\nsdata->assigned_chanctx_list while it is still an element of\nassigned_vifs list, and makes that linked list corrupt.(CVE-2021-47194)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: tipd: Remove WARN_ON in tps6598x_block_read\r\n\r\nCalling tps6598x_block_read with a higher than allowed len can be\nhandled by just returning an error. There's no need to crash systems\nwith panic-on-warn enabled.(CVE-2021-47210)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/ram: Fix crash when setting number of cpus to an odd number\r\n\r\nWhen the number of cpu cores is adjusted to 7 or other odd numbers,\nthe zone size will become an odd number.\nThe address of the zone will become:\n addr of zone0 = BASE\n addr of zone1 = BASE + zone_size\n addr of zone2 = BASE + zone_size*2\n ...\nThe address of zone1/3/5/7 will be mapped to non-alignment va.\nEventually crashes will occur when accessing these va.\r\n\r\nSo, use ALIGN_DOWN() to make sure the zone size is even\nto avoid this bug.(CVE-2023-52619)\r\n\r\nA race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.\r\n\r\n\r\n\r\n\n(CVE-2024-24860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()\r\n\r\nsyzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.\r\n\r\nReading frag_off can only be done if we pulled enough bytes\nto skb->head. Currently we might access garbage.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0\nip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0\nipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]\nip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432\n__netdev_start_xmit include/linux/netdevice.h:4940 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4954 [inline]\nxmit_one net/core/dev.c:3548 [inline]\ndev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\ndev_queue_xmit include/linux/netdevice.h:3134 [inline]\nneigh_connected_output+0x569/0x660 net/core/neighbour.c:1592\nneigh_output include/net/neighbour.h:542 [inline]\nip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137\nip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222\nNF_HOOK_COND include/linux/netfilter.h:303 [inline]\nip6_output+0x323/0x610 net/ipv6/ip6_output.c:243\ndst_output include/net/dst.h:451 [inline]\nip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155\nip6_send_skb net/ipv6/ip6_output.c:1952 [inline]\nip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972\nrawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582\nrawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920\ninet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg net/socket.c:745 [inline]\n____sys_sendmsg+0x9c2/0xd60 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/0x490 net/socket.c:2674\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\nslab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\nslab_alloc_node mm/slub.c:3478 [inline]\n__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517\n__do_kmalloc_node mm/slab_common.c:1006 [inline]\n__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027\nkmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\npskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098\n__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655\npskb_may_pull_reason include/linux/skbuff.h:2673 [inline]\npskb_may_pull include/linux/skbuff.h:2681 [inline]\nip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408\nipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]\nip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432\n__netdev_start_xmit include/linux/netdevice.h:4940 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4954 [inline]\nxmit_one net/core/dev.c:3548 [inline]\ndev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\ndev_queue_xmit include/linux/netdevice.h:3134 [inline]\nneigh_connected_output+0x569/0x660 net/core/neighbour.c:1592\nneigh_output include/net/neighbour.h:542 [inline]\nip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137\nip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222\nNF_HOOK_COND include/linux/netfilter.h:303 [inline]\nip6_output+0x323/0x610 net/ipv6/ip6_output.c:243\ndst_output include/net/dst.h:451 [inline]\nip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155\nip6_send_skb net/ipv6/ip6_output.c:1952 [inline]\nip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972\nrawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582\nrawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920\ninet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg net/socket.c:745 [inline]\n____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n__sys_sendmsg net/socket.c:2667 [inline]\n__do_sys_sendms\n---truncated---(CVE-2024-26633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don't abort filesystem when attempting to snapshot deleted subvolume\r\n\r\nIf the source file descriptor to the snapshot ioctl refers to a deleted\nsubvolume, we get the following abort:\r\n\r\n BTRFS: Transaction aborted (error -2)\n WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]\n Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c\n CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014\n RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]\n RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282\n RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027\n RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840\n RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998\n R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe\n R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80\n FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0\n Call Trace:\n \n ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n ? __warn+0x81/0x130\n ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n ? report_bug+0x171/0x1a0\n ? handle_bug+0x3a/0x70\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n create_pending_snapshots+0x92/0xc0 [btrfs]\n btrfs_commit_transaction+0x66b/0xf40 [btrfs]\n btrfs_mksubvol+0x301/0x4d0 [btrfs]\n btrfs_mksnapshot+0x80/0xb0 [btrfs]\n __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]\n btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]\n btrfs_ioctl+0x8a6/0x2650 [btrfs]\n ? kmem_cache_free+0x22/0x340\n ? do_sys_openat2+0x97/0xe0\n __x64_sys_ioctl+0x97/0xd0\n do_syscall_64+0x46/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n RIP: 0033:0x7fe20abe83af\n RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af\n RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003\n RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58\n \n ---[ end trace 0000000000000000 ]---\n BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry\n BTRFS info (device vdc: state EA): forced readonly\n BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.\n BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry\r\n\r\nThis happens because create_pending_snapshot() initializes the new root\nitem as a copy of the source root item. This includes the refs field,\nwhich is 0 for a deleted subvolume. The call to btrfs_insert_root()\ntherefore inserts a root with refs == 0. btrfs_get_new_fs_root() then\nfinds the root and returns -ENOENT if refs == 0, which causes\ncreate_pending_snapshot() to abort.\r\n\r\nFix it by checking the source root's refs before attempting the\nsnapshot, but after locking subvol_sem to avoid racing with deletion.(CVE-2024-26644)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: ep93xx: Add terminator to gpiod_lookup_table\r\n\r\nWithout the terminator, if a con_id is passed to gpio_find() that\ndoes not exist in the lookup table the function will not stop looping\ncorrectly, and eventually cause an oops.(CVE-2024-26751)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio\r\n\r\nIf kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the\nfollowing kernel warning appears:\r\n\r\nWARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8\nCall trace:\n kiocb_set_cancel_fn+0x9c/0xa8\n ffs_epfile_read_iter+0x144/0x1d0\n io_read+0x19c/0x498\n io_issue_sqe+0x118/0x27c\n io_submit_sqes+0x25c/0x5fc\n __arm64_sys_io_uring_enter+0x104/0xab0\n invoke_syscall+0x58/0x11c\n el0_svc_common+0xb4/0xf4\n do_el0_svc+0x2c/0xb0\n el0_svc+0x2c/0xa4\n el0t_64_sync_handler+0x68/0xb4\n el0t_64_sync+0x1a4/0x1a8\r\n\r\nFix this by setting the IOCB_AIO_RW flag for read and write I/O that is\nsubmitted by libaio.(CVE-2024-26764)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()\r\n\r\nPlaces the logic for checking if the group's block bitmap is corrupt under\nthe protection of the group lock to avoid allocating blocks from the group\nwith a corrupted block bitmap.(CVE-2024-26772)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()\r\n\r\nDetermine if the group block bitmap is corrupted before using ac_b_ex in\next4_mb_try_best_found() to avoid allocating blocks from a group with a\ncorrupted block bitmap in the following concurrency and making the\nsituation worse.\r\n\r\next4_mb_regular_allocator\n ext4_lock_group(sb, group)\n ext4_mb_good_group\n // check if the group bbitmap is corrupted\n ext4_mb_complex_scan_group\n // Scan group gets ac_b_ex but doesn't use it\n ext4_unlock_group(sb, group)\n ext4_mark_group_bitmap_corrupted(group)\n // The block bitmap was corrupted during\n // the group unlock gap.\n ext4_mb_try_best_found\n ext4_lock_group(ac->ac_sb, group)\n ext4_mb_use_best_found\n mb_mark_used\n // Allocating blocks in block bitmap corrupted group(CVE-2024-26773)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: sis: Error out if pixclock equals zero\r\n\r\nThe userspace program could pass any values to the driver through\nioctl() interface. If the driver doesn't check the value of pixclock,\nit may cause divide-by-zero error.\r\n\r\nIn sisfb_check_var(), var->pixclock is used as a divisor to caculate\ndrate before it is checked against zero. Fix this by checking it\nat the beginning.\r\n\r\nThis is similar to CVE-2022-3061 in i740fb which was fixed by\ncommit 15cf0b8.(CVE-2024-26777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: savage: Error out if pixclock equals zero\r\n\r\nThe userspace program could pass any values to the driver through\nioctl() interface. If the driver doesn't check the value of pixclock,\nit may cause divide-by-zero error.\r\n\r\nAlthough pixclock is checked in savagefb_decode_var(), but it is not\nchecked properly in savagefb_probe(). Fix this by checking whether\npixclock is zero in the function savagefb_check_var() before\ninfo->var.pixclock is used as the divisor.\r\n\r\nThis is similar to CVE-2022-3061 in i740fb which was fixed by\ncommit 15cf0b8.(CVE-2024-26778)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: Lock external INTx masking ops\r\n\r\nMask operations through config space changes to DisINTx may race INTx\nconfiguration changes via ioctl. Create wrappers that add locking for\npaths outside of the core interrupt code.\r\n\r\nIn particular, irq_type is updated holding igate, therefore testing\nis_intx() requires holding igate. For example clearing DisINTx from\nconfig space can otherwise race changes of the interrupt configuration.\r\n\r\nThis aligns interfaces which may trigger the INTx eventfd into two\ncamps, one side serialized by igate and the other only enabled while\nINTx is configured. A subsequent patch introduces synchronization for\nthe latter flows.(CVE-2024-26810)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fix hashtab overflow check on 32-bit arches\r\n\r\nThe hashtab code relies on roundup_pow_of_two() to compute the number of\nhash buckets, and contains an overflow check by checking if the\nresulting value is 0. However, on 32-bit arches, the roundup code itself\ncan overflow by doing a 32-bit left-shift of an unsigned long value,\nwhich is undefined behaviour, so it is not guaranteed to truncate\nneatly. This was triggered by syzbot on the DEVMAP_HASH type, which\ncontains the same check, copied from the hashtab code. So apply the same\nfix to hashtab, by moving the overflow check to before the roundup.(CVE-2024-26884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: Disable auto-enable of exclusive INTx IRQ\r\n\r\nCurrently for devices requiring masking at the irqchip for INTx, ie.\ndevices without DisINTx support, the IRQ is enabled in request_irq()\nand subsequently disabled as necessary to align with the masked status\nflag. This presents a window where the interrupt could fire between\nthese events, resulting in the IRQ incrementing the disable depth twice.\nThis would be unrecoverable for a user since the masked flag prevents\nnested enables through vfio.\r\n\r\nInstead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx\nis never auto-enabled, then unmask as required.(CVE-2024-27437)", + "cves": [ + { + "id": "CVE-2021-47210", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47210", + "severity": "Medium" + }, + { + "id": "CVE-2024-27437", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27437", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2024-1256": { + "id": "openEuler-SA-2024-1256", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1256", + "title": "An update for rubygem-yard is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS,openEuler-22.03-LTS-SP1,openEuler-22.03-LTS-SP2 and openEuler-22.03-LTS-SP3", + "severity": "Medium", + "description": "YARD is a documentation generation tool for the Ruby programming language. It enables the user to generate consistent, usable documentation that can be exported to a number of formats very easily, and also supports extending for custom Ruby constructs such as custom class level definitions.\r\n\r\nSecurity Fix(es):\r\n\r\nYARD is a Ruby Documentation tool. The \"frames.html\" file within the Yard Doc's generated documentation is vulnerable to Cross-Site Scripting (XSS) attacks due to inadequate sanitization of user input within the JavaScript segment of the \"frames.erb\" template file. This vulnerability is fixed in 0.9.36.(CVE-2024-27285)", + "cves": [ + { + "id": "CVE-2024-27285", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27285", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1545": { + "id": "openEuler-SA-2023-1545", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1545", + "title": "An update for qt is now available for openEuler-20.03-LTS-SP1", + "severity": "Medium", + "description": "Qt (pronounced as \"cute\", not \"cu-tee\") is a cross-platform framework that is usually used as a graphical toolkit, although it is also very helpful in creating CLI applications. It runs on the three major desktop OSes, as well as on mobile OSes, such as Symbian, Nokia Belle, Meego Harmattan, MeeGo or BB10, and on embedded devices. Ports for Android (Necessitas) and iOS are also in development\n\nSecurity Fix(es):\n\nIn Qt before 5.15.14, 6.0.x through 6.2.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1, QtSvg QSvgFont m_unitsPerEm initialization is mishandled.(CVE-2023-32573)", + "cves": [ + { + "id": "CVE-2023-32573", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32573", + "severity": "Medium" + } + ] + }, + "openEuler-SA-2023-1673": { + "id": "openEuler-SA-2023-1673", + "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2023-1673", + "title": "An update for firefox is now available for openEuler-22.03-LTS", + "severity": "Critical", + "description": "Mozilla Firefox is a standalone web browser, designed for standards compliance and performance. Its functionality can be enhanced via a plethora of extensions.\r\n\r\nMozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability.\r\n\r\nSecurity Fix(es):\r\n\r\nMozilla developers reported memory safety bugs present in Firefox for Android 79. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 80, Firefox ESR < 78.2, Thunderbird < 78.2, and Firefox for Android < 80.(CVE-2020-15670)\r\n\r\nMozilla developers reported memory safety bugs present in Firefox 80 and Firefox ESR 78.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 81, Thunderbird < 78.3, and Firefox ESR < 78.3.(CVE-2020-15673)\r\n\r\nMozilla developers reported memory safety bugs present in Firefox 80. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 81.(CVE-2020-15674)\r\n\r\nWhen processing surfaces, the lifetime may outlive a persistent buffer leading to memory corruption and a potentially exploitable crash. This vulnerability affects Firefox < 81.(CVE-2020-15675)\r\n\r\nIf a valid external protocol handler was referenced in an image tag, the resulting broken image size could be distinguished from a broken image size of a non-existent protocol handler. This allowed an attacker to successfully probe whether an external protocol handler was registered. This vulnerability affects Firefox < 82.(CVE-2020-15680)\r\n\r\nWhen multiple WASM threads had a reference to a module, and were looking up exported functions, one WASM thread could have overwritten another's entry in a shared stub table, resulting in a potentially exploitable crash. This vulnerability affects Firefox < 82.(CVE-2020-15681)\r\n\r\nWhen a link to an external protocol was clicked, a prompt was presented that allowed the user to choose what application to open it in. An attacker could induce that prompt to be associated with an origin they didn't control, resulting in a spoofing attack. This was fixed by changing external protocol prompts to be tab-modal while also ensuring they could not be incorrectly associated with a different origin. This vulnerability affects Firefox < 82.(CVE-2020-15682)\r\n\r\nMozilla developers and community members reported memory safety bugs present in Firefox 81 and Firefox ESR 78.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR < 78.4, Firefox < 82, and Thunderbird < 78.4.(CVE-2020-15683)\r\n\r\nMozilla developers reported memory safety bugs present in Firefox 81. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 82.(CVE-2020-15684)\r\n\r\nSide-channel information leakage in graphics in Google Chrome prior to 87.0.4280.66 allowed a remote attacker to leak cross-origin data via a crafted HTML page.(CVE-2020-16012)\r\n\r\nUse after free in WebRTC in Google Chrome prior to 88.0.4324.96 allowed a remote attacker to potentially exploit heap corruption via a crafted SCTP packet.(CVE-2020-16044)\r\n\r\nIn certain circumstances, the MCallGetProperty opcode can be emitted with unmet assumptions resulting in an exploitable use-after-free condition. This vulnerability affects Firefox < 82.0.3, Firefox ESR < 78.4.1, and Thunderbird < 78.4.2.(CVE-2020-26950)\r\n\r\n(CVE-2020-26951)\r\n\r\n(CVE-2020-26953)\r\n\r\n(CVE-2020-26956)\r\n\r\n(CVE-2020-26958)\r\n\r\n(CVE-2020-26959)\r\n\r\n(CVE-2020-26960)\r\n\r\n(CVE-2020-26961)\r\n\r\n(CVE-2020-26962)\r\n\r\n(CVE-2020-26965)\r\n\r\n(CVE-2020-26968)\r\n\r\n(CVE-2020-26969)\r\n\r\nCertain blit values provided by the user were not properly constrained leading to a heap buffer overflow on some video drivers. This vulnerability affects Firefox < 84, Thunderbird < 78.6, and Firefox ESR < 78.6.(CVE-2020-26971)\r\n\r\nThe lifecycle of IPC Actors allows managed actors to outlive their manager actors; and the former must ensure that they are not attempting to use a dead actor they have a reference to. Such a check was omitted in WebGL, resulting in a use-after-free and a potentially exploitable crash. This vulnerability affects Firefox < 84.(CVE-2020-26972)\r\n\r\nCertain input to the CSS Sanitizer confused it, resulting in incorrect components being removed. This could have been used as a sanitizer bypass. This vulnerability affects Firefox < 84, Thunderbird < 78.6, and Firefox ESR < 78.6.(CVE-2020-26973)\r\n\r\nWhen flex-basis was used on a table wrapper, a StyleGenericFlexBasis object could have been incorrectly cast to the wrong type. This resulted in a heap user-after-free, memory corruption, and a potentially exploitable crash. This vulnerability affects Firefox < 84, Thunderbird < 78.6, and Firefox ESR < 78.6.(CVE-2020-26974)\r\n\r\nWhen a HTTPS pages was embedded in a HTTP page, and there was a service worker registered for the former, the service worker could have intercepted the request for the secure page despite the iframe not being a secure context due to the (insecure) framing. This vulnerability affects Firefox < 84.(CVE-2020-26976)\r\n\r\nUsing techniques that built on the slipstream research, a malicious webpage could have exposed both an internal network's hosts as well as services running on the user's local machine. This vulnerability affects Firefox < 84, Thunderbird < 78.6, and Firefox ESR < 78.6.(CVE-2020-26978)\r\n\r\nWhen a user typed a URL in the address bar or the search bar and quickly hit the enter key, a website could sometimes capture that event and then redirect the user before navigation occurred to the desired, entered address. To construct a convincing spoof the attacker would have had to guess what the user was typing, perhaps by suggesting it. This vulnerability affects Firefox < 84.(CVE-2020-26979)\r\n\r\nWhen an extension with the proxy permission registered to receive , the proxy.onRequest callback was not triggered for view-source URLs. While web content cannot navigate to such URLs, a user opening View Source could have inadvertently leaked their IP address. This vulnerability affects Firefox < 84, Thunderbird < 78.6, and Firefox ESR < 78.6.(CVE-2020-35111)\r\n\r\nMozilla developers reported memory safety bugs present in Firefox 83 and Firefox ESR 78.5. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 84, Thunderbird < 78.6, and Firefox ESR < 78.6.(CVE-2020-35113)\r\n\r\nMozilla developers reported memory safety bugs present in Firefox 83. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 84.(CVE-2020-35114)\r\n\r\nIf a user clicked into a specifically crafted PDF, the PDF reader could be confused into leaking cross-origin information, when said information is served as chunked data. This vulnerability affects Firefox < 85, Thunderbird < 78.7, and Firefox ESR < 78.7.(CVE-2021-23953)\r\n\r\nUsing the new logical assignment operators in a JavaScript switch statement could have caused a type confusion, leading to a memory corruption and a potentially exploitable crash. This vulnerability affects Firefox < 85, Thunderbird < 78.7, and Firefox ESR < 78.7.(CVE-2021-23954)\r\n\r\nThe browser could have been confused into transferring a pointer lock state into another tab, which could have lead to clickjacking attacks. This vulnerability affects Firefox < 85.(CVE-2021-23955)\r\n\r\nAn ambiguous file picker design could have confused users who intended to select and upload a single file into uploading a whole directory. This was addressed by adding a new prompt. This vulnerability affects Firefox < 85.(CVE-2021-23956)\r\n\r\nThe browser could have been confused into transferring a screen sharing state into another tab, which would leak unintended information. This vulnerability affects Firefox < 85.(CVE-2021-23958)\r\n\r\nPerforming garbage collection on re-declared JavaScript variables resulted in a user-after-poison, and a potentially exploitable crash. This vulnerability affects Firefox < 85, Thunderbird < 78.7, and Firefox ESR < 78.7.(CVE-2021-23960)\r\n\r\nFurther techniques that built on the slipstream research combined with a malicious webpage could have exposed both an internal network's hosts as well as services running on the user's local machine. This vulnerability affects Firefox < 85.(CVE-2021-23961)\r\n\r\nIncorrect use of the '' method could have led to a user-after-poison and a potentially exploitable crash. This vulnerability affects Firefox < 85.(CVE-2021-23962)\r\n\r\nWhen sharing geolocation during an active WebRTC share, Firefox could have reset the webRTC sharing state in the user interface, leading to loss of control over the currently granted permission. This vulnerability affects Firefox < 85.(CVE-2021-23963)\r\n\r\nMozilla developers reported memory safety bugs present in Firefox 84 and Firefox ESR 78.6. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 85, Thunderbird < 78.7, and Firefox ESR < 78.7.(CVE-2021-23964)\r\n\r\nMozilla developers reported memory safety bugs present in Firefox 84. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 85.(CVE-2021-23965)\r\n\r\nIf Content Security Policy blocked frame navigation, the full destination of a redirect served in the frame was reported in the violation report; as opposed to the original frame URI. This could be used to leak sensitive information contained in such URIs. This vulnerability affects Firefox < 86, Thunderbird < 78.8, and Firefox ESR < 78.8.(CVE-2021-23968)\r\n\r\nAs specified in the W3C Content Security Policy draft, when creating a violation report, \"User agents need to ensure that the source file is the URL requested by the page, pre-redirects. If that’s not possible, user agents need to strip the URL down to an origin to avoid unintentional leakage.\" Under certain types of redirects, Firefox incorrectly set the source file to be the destination of the redirects. This was fixed to be the redirect destination's origin. This vulnerability affects Firefox < 86, Thunderbird < 78.8, and Firefox ESR < 78.8.(CVE-2021-23969)\r\n\r\nContext-specific code was included in a shared jump table; resulting in assertions being triggered in multithreaded wasm code. This vulnerability affects Firefox < 86.(CVE-2021-23970)\r\n\r\nWhen processing a redirect with a conflicting Referrer-Policy, Firefox would have adopted the redirect's Referrer-Policy. This would have potentially resulted in more information than intended by the original origin being provided to the destination of the redirect. This vulnerability affects Firefox < 86.(CVE-2021-23971)\r\n\r\nOne phishing tactic on the web is to provide a link with HTTP Auth. For example 'https://www.phishingtarget.com@evil.com'. To mitigate this type of attack, Firefox will display a warning dialog; however, this warning dialog would not have been displayed if evil.com used a redirect that was cached by the browser. This vulnerability affects Firefox < 86.(CVE-2021-23972)\r\n\r\nWhen trying to load a cross-origin resource in an audio/video context a decoding error may have resulted, and the content of that error may have revealed information about the resource. This vulnerability affects Firefox < 86, Thunderbird < 78.8, and Firefox ESR < 78.8.(CVE-2021-23973)\r\n\r\nThe DOMParser API did not properly process '