{"id":"CVE-2024-42067","aliases":["AZL-47137","AZL-47157","BELL-CVE-2024-42067","DEBIAN-CVE-2024-42067","EUVD-2024-39899","GHSA-x8rh-6x6w-x2xg","MGASA-2024-0277","MGASA-2024-0278","OESA-2024-2219","OESA-2024-2255","OESA-2024-2257","OESA-2024-2258","ROOT-OS-DEBIAN-11-CVE-2024-42067","ROOT-OS-DEBIAN-12-CVE-2024-42067","ROOT-OS-UBUNTU-2204-CVE-2024-42067","UBUNTU-CVE-2024-42067","USN-7089-1","USN-7089-2","USN-7089-3","USN-7089-4","USN-7089-5","USN-7089-6","USN-7089-7","USN-7090-1","USN-7095-1","USN-7156-1"],"status":"published","title":"bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\n\nset_memory_rox() can fail, leaving memory unprotected.\n\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.","severity":{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00301,"percentile":0.23119,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-252"],"published":"2024-07-29T15:52:31Z","modified":"2026-11-12T17:24:21Z","fixes":[{"ecosystem":"Azure Linux:3","package":"kernel","fixed_in":["6.6.43.1-7"],"sources":["osv"]},{"ecosystem":"Alpaquita:25","package":"linux-lts","fixed_in":["6.12.41-r0"],"sources":["osv"]},{"ecosystem":"Alpaquita:stream","package":"linux-lts","fixed_in":["6.12.41-r0"],"sources":["osv"]},{"ecosystem":"Linux","package":"Kernel","fixed_in":["6.6.160","6.9.8"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"linux","fixed_in":["6.9.8-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"linux","fixed_in":["6.9.8-1"],"sources":["osv"]},{"ecosystem":"Root:Debian:11","package":"linux","fixed_in":["5.10.262-1.aikido.113","5.10.262-1.aikido.114"],"sources":["osv"]},{"ecosystem":"Root:Debian:11","package":"rootio-linux","fixed_in":["5.10.262-1.aikido.113","5.10.262-1.aikido.114"],"sources":["osv"]},{"ecosystem":"Root:Debian:12","package":"linux","fixed_in":["6.1.190-1.aikido.167"],"sources":["osv"]},{"ecosystem":"Root:Debian:12","package":"rootio-linux","fixed_in":["6.1.190-1.aikido.167"],"sources":["osv"]},{"ecosystem":"Root:Ubuntu:22.04","package":"linux","fixed_in":["5.15.0-203.213.aikido.119"],"sources":["osv"]},{"ecosystem":"Root:Ubuntu:22.04","package":"rootio-linux","fixed_in":["5.15.0-203.213.aikido.119"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-6.8","fixed_in":["6.8.0-1018.19~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-6.8","fixed_in":["6.8.0-1017.20~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-6.8","fixed_in":["6.8.0-1017.19~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-hwe-6.8","fixed_in":["6.8.0-48.48~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-ibm-6.8","fixed_in":["6.8.0-1015.15~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-6.8","fixed_in":["6.8.0-48.48.3~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-6.8","fixed_in":["6.8.0-1017.19~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-oracle-6.8","fixed_in":["6.8.0-1015.15~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-riscv-6.8","fixed_in":["6.8.0-48.48.1~22.04.2"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:Realtime:22.04:LTS","package":"linux-realtime-6.8","fixed_in":["6.8.1-1011.11~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux","fixed_in":["6.8.0-48.48"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-aws","fixed_in":["6.8.0-1018.20"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure","fixed_in":["6.8.0-1017.20"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp","fixed_in":["6.8.0-1017.19"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-gke","fixed_in":["6.8.0-1013.17"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-gkeop","fixed_in":["6.8.0-1002.4"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-ibm","fixed_in":["6.8.0-1015.15"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-lowlatency","fixed_in":["6.8.0-48.48.3"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia","fixed_in":["6.8.0-1017.19"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia-lowlatency","fixed_in":["6.8.0-1017.19.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.8","fixed_in":["6.8.0-1016.16"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-oracle","fixed_in":["6.8.0-1015.16"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-raspi","fixed_in":["6.8.0-1014.16"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-riscv","fixed_in":["6.8.0-48.48.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-xilinx","fixed_in":["6.8.0-1009.10"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-raspi-realtime","fixed_in":["6.8.0-2013.14"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-realtime","fixed_in":["6.8.1-1011.11"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:FIPS-updates:24.04:LTS","package":"linux-fips","fixed_in":["6.8.0-78.78+fips1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Azure Linux:2","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"5.15.200.1-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.43.1-7"}]}]},{"source":"osv","ecosystem":"Alpaquita:25","package":"linux-lts","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.6.89-r0"},{"fixed":"6.12.41-r0"}]}]},{"source":"osv","ecosystem":"Alpaquita:stream","package":"linux-lts","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.6.100-r0"},{"fixed":"6.12.41-r0"}]}]},{"source":"osv","ecosystem":"Linux","package":"Kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.2.0"},{"fixed":"6.6.160"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.7.0"},{"fixed":"6.9.8"}]}]},{"source":"osv","ecosystem":"Debian:13","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.9.8-1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.9.8-1"}]}]},{"source":"osv","ecosystem":"Mageia:9","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.43-1.mga9"}]}],"bundled":109},{"source":"osv","ecosystem":"Mageia:9","package":"kmod-xtables-addons","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.24-60.mga9"}]}],"bundled":109},{"source":"osv","ecosystem":"Mageia:9","package":"kmod-virtualbox","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"7.0.20-52.mga9"}]}],"bundled":109},{"source":"osv","ecosystem":"Mageia:9","package":"kernel-linus","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.43-1.mga9"}]}],"bundled":109},{"source":"osv","ecosystem":"openEuler:24.03-LTS","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-46.0.0.51.oe2403"}]}],"bundled":69},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP3","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-232.0.0.134.oe2203sp3"}]}],"bundled":46},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP1","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-136.97.0.178.oe2203sp1"}]}],"bundled":46},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP4","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-232.0.0.131.oe2203sp4"}]}],"bundled":72},{"source":"osv","ecosystem":"Root:Debian:11","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.262-1.aikido.113"},{"fixed":"5.10.262-1.aikido.114"}]}]},{"source":"osv","ecosystem":"Root:Debian:11","package":"rootio-linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.262-1.aikido.113"},{"fixed":"5.10.262-1.aikido.114"}]}]},{"source":"osv","ecosystem":"Root:Debian:12","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.190-1.aikido.167"}]}]},{"source":"osv","ecosystem":"Root:Debian:12","package":"rootio-linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.190-1.aikido.167"}]}]},{"source":"osv","ecosystem":"Root:Ubuntu:22.04","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-203.213.aikido.119"}]}]},{"source":"osv","ecosystem":"Root:Ubuntu:22.04","package":"rootio-linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-203.213.aikido.119"}]}]},{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"linux-hwe-edge","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.8.0-28.30~16.04.1","4.8.0-30.32~16.04.1","4.8.0-32.34~16.04.1","4.8.0-34.36~16.04.1","4.10.0-14.16~16.04.1","4.10.0-19.21~16.04.1","4.10.0-20.22~16.04.1","4.10.0-21.23~16.04.1","4.10.0-22.24~16.04.1","4.10.0-24.28~16.04.1","4.10.0-26.30~16.04.1","4.11.0-13.19~16.04.1","4.11.0-14.20~16.04.1","4.13.0-16.19~16.04.3","4.13.0-17.20~16.04.1","4.13.0-19.22~16.04.1","4.13.0-21.24~16.04.1","4.13.0-25.29~16.04.2","4.15.0-13.14~16.04.1","4.15.0-15.16~16.04.1","4.15.0-20.21~16.04.1","4.15.0-22.24~16.04.1","4.15.0-23.25~16.04.1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-aws-5.0","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.0.0-1021.24~18.04.1","5.0.0-1022.25~18.04.1","5.0.0-1023.26~18.04.1","5.0.0-1024.27~18.04.1","5.0.0-1025.28","5.0.0-1027.30"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-aws-5.3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1016.17~18.04.1","5.3.0-1017.18~18.04.1","5.3.0-1019.21~18.04.1","5.3.0-1023.25~18.04.1","5.3.0-1028.30~18.04.1","5.3.0-1030.32~18.04.1","5.3.0-1032.34~18.04.2","5.3.0-1033.35","5.3.0-1034.36","5.3.0-1035.37"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-azure","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.15.0-1002.2","4.15.0-1003.3","4.15.0-1004.4","4.15.0-1008.8","4.15.0-1009.9","4.15.0-1012.12","4.15.0-1013.13","4.15.0-1014.14","4.15.0-1018.18","4.15.0-1019.19","4.15.0-1021.21","4.15.0-1022.23","4.15.0-1023.24","4.15.0-1025.26","4.15.0-1028.29","4.15.0-1030.31","4.15.0-1031.32","4.15.0-1032.33","4.15.0-1035.36","4.15.0-1036.38","4.15.0-1037.39","4.18.0-1011.11~18.04.1","4.18.0-1013.13~18.04.1","4.18.0-1014.14~18.04.1","4.18.0-1018.18~18.04.1","4.18.0-1019.19~18.04.1","4.18.0-1020.20~18.04.1","4.18.0-1023.24~18.04.1","4.18.0-1024.25~18.04.1","4.18.0-1025.27~18.04.1","5.0.0-1014.14~18.04.1","5.0.0-1016.17~18.04.1","5.0.0-1018.19~18.04.1","5.0.0-1020.21~18.04.1","5.0.0-1022.23~18.04.1","5.0.0-1023.24~18.04.1","5.0.0-1025.27~18.04.1","5.0.0-1027.29~18.04.1","5.0.0-1028.30~18.04.1","5.0.0-1029.31~18.04.1","5.0.0-1031.33","5.0.0-1032.34","5.0.0-1035.37","5.0.0-1036.38"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-azure-5.3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1007.8~18.04.1","5.3.0-1008.9~18.04.1","5.3.0-1009.10~18.04.1","5.3.0-1010.11~18.04.1","5.3.0-1012.13~18.04.1","5.3.0-1013.14~18.04.1","5.3.0-1016.17~18.04.1","5.3.0-1018.19~18.04.1","5.3.0-1019.20~18.04.1","5.3.0-1020.21~18.04.1","5.3.0-1022.23~18.04.1","5.3.0-1028.29~18.04.1","5.3.0-1031.32~18.04.1","5.3.0-1032.33~18.04.1","5.3.0-1034.35~18.04.1","5.3.0-1035.36"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-azure-edge","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.18.0-1006.6~18.04.1","4.18.0-1007.7~18.04.1","4.18.0-1008.8~18.04.1","5.0.0-1012.12~18.04.2"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.15.0-1001.1","4.15.0-1003.3","4.15.0-1005.5","4.15.0-1006.6","4.15.0-1008.8","4.15.0-1009.9","4.15.0-1010.10","4.15.0-1014.14","4.15.0-1015.15","4.15.0-1017.18","4.15.0-1018.19","4.15.0-1019.20","4.15.0-1021.22","4.15.0-1023.24","4.15.0-1024.25","4.15.0-1025.26","4.15.0-1026.27","4.15.0-1027.28","4.15.0-1028.29","4.15.0-1029.31","4.15.0-1030.32","4.15.0-1032.34","4.15.0-1033.35","4.15.0-1034.36","4.15.0-1036.38","4.15.0-1037.39","4.15.0-1040.42","4.15.0-1042.45","4.15.0-1044.70","5.0.0-1020.20~18.04.1","5.0.0-1021.21~18.04.1","5.0.0-1025.26~18.04.1","5.0.0-1026.27~18.04.1","5.0.0-1028.29~18.04.1","5.0.0-1029.30~18.04.1","5.0.0-1031.32","5.0.0-1033.34","5.0.0-1034.35"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gcp-5.3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1008.9~18.04.1","5.3.0-1009.10~18.04.1","5.3.0-1010.11~18.04.1","5.3.0-1012.13~18.04.1","5.3.0-1014.15~18.04.1","5.3.0-1016.17~18.04.1","5.3.0-1017.18~18.04.1","5.3.0-1018.19~18.04.1","5.3.0-1020.22~18.04.1","5.3.0-1026.28~18.04.1","5.3.0-1029.31~18.04.1","5.3.0-1030.32~18.04.1","5.3.0-1032.34~18.04.1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gke-4.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.15.0-1030.32","4.15.0-1032.34","4.15.0-1033.35","4.15.0-1034.36","4.15.0-1036.38","4.15.0-1037.39","4.15.0-1040.42","4.15.0-1041.43","4.15.0-1042.44","4.15.0-1044.46","4.15.0-1045.48","4.15.0-1046.49","4.15.0-1048.51","4.15.0-1049.52","4.15.0-1050.53","4.15.0-1052.55","4.15.0-1055.58","4.15.0-1057.60","4.15.0-1058.61","4.15.0-1059.62","4.15.0-1063.66","4.15.0-1064.67","4.15.0-1066.69","4.15.0-1067.70","4.15.0-1069.72","4.15.0-1070.73","4.15.0-1072.76","4.15.0-1073.78","4.15.0-1074.79","4.15.0-1076.81","4.15.0-1077.82","4.15.0-1078.83","4.15.0-1079.84"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gke-5.4","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1025.25~18.04.1","5.4.0-1027.28~18.04.1","5.4.0-1029.31~18.04.1","5.4.0-1030.32~18.04.1","5.4.0-1032.34~18.04.1","5.4.0-1033.35~18.04.1","5.4.0-1035.37~18.04.1","5.4.0-1036.38~18.04.1","5.4.0-1037.39~18.04.1","5.4.0-1039.41~18.04.1","5.4.0-1040.42~18.04.1","5.4.0-1042.44~18.04.1","5.4.0-1043.45~18.04.1","5.4.0-1044.46~18.04.1","5.4.0-1046.48~18.04.1","5.4.0-1049.52~18.04.1","5.4.0-1051.54~18.04.1","5.4.0-1052.55~18.04.1","5.4.0-1053.56~18.04.1","5.4.0-1054.57~18.04.1","5.4.0-1055.58~18.04.1","5.4.0-1056.59~18.04.1","5.4.0-1057.60~18.04.1","5.4.0-1059.62~18.04.1","5.4.0-1061.64~18.04.1","5.4.0-1062.65~18.04.1","5.4.0-1063.66~18.04.1","5.4.0-1065.68~18.04.1","5.4.0-1066.69~18.04.1","5.4.0-1067.70~18.04.1","5.4.0-1068.71~18.04.1","5.4.0-1071.76~18.04.3","5.4.0-1072.77~18.04.1","5.4.0-1074.79~18.04.1","5.4.0-1076.82~18.04.1","5.4.0-1078.84~18.04.1","5.4.0-1080.86~18.04.1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gkeop-5.4","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1001.1","5.4.0-1003.3","5.4.0-1004.5","5.4.0-1005.6","5.4.0-1007.8~18.04.1","5.4.0-1008.9~18.04.1","5.4.0-1009.10~18.04.1","5.4.0-1010.11~18.04.1","5.4.0-1011.12~18.04.2","5.4.0-1012.13~18.04.1","5.4.0-1013.14~18.04.1","5.4.0-1014.15~18.04.1","5.4.0-1015.16~18.04.1","5.4.0-1016.17~18.04.1","5.4.0-1018.19~18.04.1","5.4.0-1021.22~18.04.1","5.4.0-1022.23~18.04.1","5.4.0-1023.24~18.04.1","5.4.0-1024.25~18.04.1","5.4.0-1025.26~18.04.1","5.4.0-1026.27~18.04.1","5.4.0-1027.28~18.04.1","5.4.0-1029.30~18.04.2","5.4.0-1031.32~18.04.1","5.4.0-1032.33~18.04.1","5.4.0-1033.34~18.04.1","5.4.0-1034.35~18.04.1","5.4.0-1036.37~18.04.1","5.4.0-1037.38~18.04.1","5.4.0-1038.39~18.04.1","5.4.0-1039.40~18.04.1","5.4.0-1040.41~18.04.1","5.4.0-1043.44~18.04.1","5.4.0-1046.48~18.04.1","5.4.0-1048.51~18.04.1","5.4.0-1049.52~18.04.1","5.4.0-1051.54~18.04.1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-hwe","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.18.0-13.14~18.04.1","4.18.0-14.15~18.04.1","4.18.0-15.16~18.04.1","4.18.0-16.17~18.04.1","4.18.0-17.18~18.04.1","4.18.0-18.19~18.04.1","4.18.0-20.21~18.04.1","4.18.0-21.22~18.04.1","4.18.0-22.23~18.04.1","4.18.0-24.25~18.04.1","4.18.0-25.26~18.04.1","5.0.0-23.24~18.04.1","5.0.0-25.26~18.04.1","5.0.0-27.28~18.04.1","5.0.0-29.31~18.04.1","5.0.0-31.33~18.04.1","5.0.0-32.34~18.04.2","5.0.0-35.38~18.04.1","5.0.0-36.39~18.04.1","5.0.0-37.40~18.04.1","5.3.0-26.28~18.04.1","5.3.0-28.30~18.04.1","5.3.0-40.32~18.04.1","5.3.0-42.34~18.04.1","5.3.0-45.37~18.04.1","5.3.0-46.38~18.04.1","5.3.0-51.44~18.04.2","5.3.0-53.47~18.04.1","5.3.0-59.53~18.04.1","5.3.0-61.55~18.04.1","5.3.0-62.56~18.04.1","5.3.0-64.58~18.04.1","5.3.0-65.59","5.3.0-66.60","5.3.0-67.61","5.3.0-68.63","5.3.0-69.65","5.3.0-70.66","5.3.0-72.68","5.3.0-73.69","5.3.0-74.70","5.3.0-75.71","5.3.0-76.72"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-hwe-edge","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.0.0-15.16~18.04.1","5.0.0-16.17~18.04.1","5.0.0-17.18~18.04.1","5.0.0-19.20~18.04.1","5.0.0-20.21~18.04.1","5.3.0-19.20~18.04.2","5.3.0-22.24~18.04.1","5.3.0-23.25~18.04.1","5.3.0-23.25~18.04.2","5.3.0-24.26~18.04.2"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-oem","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.15.0-1002.3","4.15.0-1004.5","4.15.0-1006.9","4.15.0-1008.11","4.15.0-1009.12","4.15.0-1012.15","4.15.0-1013.16","4.15.0-1015.18","4.15.0-1017.20","4.15.0-1018.21","4.15.0-1021.24","4.15.0-1024.29","4.15.0-1026.31","4.15.0-1028.33","4.15.0-1030.35","4.15.0-1033.38","4.15.0-1034.39","4.15.0-1035.40","4.15.0-1036.41","4.15.0-1038.43","4.15.0-1039.44","4.15.0-1043.48","4.15.0-1045.50","4.15.0-1050.57","4.15.0-1056.65","4.15.0-1057.66","4.15.0-1059.68","4.15.0-1063.72","4.15.0-1064.73","4.15.0-1065.75","4.15.0-1066.76","4.15.0-1067.77","4.15.0-1069.79","4.15.0-1073.83","4.15.0-1076.86","4.15.0-1079.89","4.15.0-1080.90","4.15.0-1081.91","4.15.0-1087.97","4.15.0-1090.100","4.15.0-1091.101","4.15.0-1093.103","4.15.0-1094.104","4.15.0-1096.106","4.15.0-1097.107","4.15.0-1099.109","4.15.0-1100.110","4.15.0-1101.112","4.15.0-1102.113","4.15.0-1103.114"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-oracle-5.0","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.0.0-1007.12~18.04.1","5.0.0-1008.13~18.04.1","5.0.0-1009.14~18.04.1","5.0.0-1010.15~18.04.1","5.0.0-1011.16","5.0.0-1013.18","5.0.0-1014.19"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-oracle-5.3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1011.12~18.04.1","5.3.0-1013.14~18.04.1","5.3.0-1014.15~18.04.1","5.3.0-1016.18~18.04.1","5.3.0-1018.20~18.04.1","5.3.0-1024.26~18.04.1","5.3.0-1027.29~18.04.1","5.3.0-1028.30~18.04.1","5.3.0-1030.32~18.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-aws-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1009.9~20.04.2","5.11.0-1014.15~20.04.1","5.11.0-1016.17~20.04.1","5.11.0-1017.18~20.04.1","5.11.0-1019.20~20.04.1","5.11.0-1020.21~20.04.2","5.11.0-1021.22~20.04.2","5.11.0-1022.23~20.04.1","5.11.0-1023.24~20.04.1","5.11.0-1025.27~20.04.1","5.11.0-1027.30~20.04.1","5.11.0-1028.31~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-aws-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1008.9~20.04.2","5.13.0-1011.12~20.04.1","5.13.0-1012.13~20.04.1","5.13.0-1014.15~20.04.1","5.13.0-1017.19~20.04.1","5.13.0-1019.21~20.04.1","5.13.0-1021.23~20.04.2","5.13.0-1022.24~20.04.1","5.13.0-1023.25~20.04.1","5.13.0-1025.27~20.04.1","5.13.0-1028.31~20.04.1","5.13.0-1029.32~20.04.1","5.13.0-1031.35~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-aws-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-1035.37~20.04.1","5.8.0-1038.40~20.04.1","5.8.0-1041.43~20.04.1","5.8.0-1042.44~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1007.7~20.04.2","5.11.0-1012.13~20.04.1","5.11.0-1013.14~20.04.1","5.11.0-1015.16~20.04.1","5.11.0-1017.18~20.04.1","5.11.0-1019.20~20.04.1","5.11.0-1020.21~20.04.1","5.11.0-1021.22~20.04.1","5.11.0-1022.23~20.04.1","5.11.0-1023.24~20.04.1","5.11.0-1025.27~20.04.1","5.11.0-1027.30~20.04.1","5.11.0-1028.31~20.04.2"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1009.10~20.04.2","5.13.0-1012.14~20.04.1","5.13.0-1013.15~20.04.1","5.13.0-1014.16~20.04.1","5.13.0-1017.19~20.04.1","5.13.0-1021.24~20.04.1","5.13.0-1022.26~20.04.1","5.13.0-1023.27~20.04.1","5.13.0-1025.29~20.04.1","5.13.0-1028.33~20.04.1","5.13.0-1029.34~20.04.1","5.13.0-1031.37~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-1033.35~20.04.1","5.8.0-1036.38~20.04.1","5.8.0-1039.42~20.04.1","5.8.0-1040.43~20.04.1","5.8.0-1041.44~20.04.1","5.8.0-1042.45~20.04.1","5.8.0-1043.46~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-fde","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1063.66+cvm2.2","5.4.0-1063.66+cvm3.2","5.4.0-1064.67+cvm1.1","5.4.0-1065.68+cvm2.1","5.4.0-1067.70+cvm1.1","5.4.0-1068.71+cvm1.1","5.4.0-1069.72+cvm1.1","5.4.0-1070.73+cvm1.1","5.4.0-1072.75+cvm1.1","5.4.0-1073.76+cvm1.1","5.4.0-1074.77+cvm1.1","5.4.0-1076.79+cvm1.1","5.4.0-1078.81+cvm1.1","5.4.0-1080.83+cvm1.1","5.4.0-1083.87+cvm1.1","5.4.0-1085.90+cvm1.1","5.4.0-1085.90+cvm2.1","5.4.0-1086.91+cvm1.1","5.4.0-1089.94+cvm1.2","5.4.0-1090.95+cvm1.1","5.4.0-1091.96+cvm1.1","5.4.0-1092.97+cvm1.1","5.4.0-1095.101+cvm1.1","5.4.0-1098.104+cvm1.1","5.4.0-1100.106+cvm1.1","5.4.0-1103.109+cvm1.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gcp-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1009.10~20.04.1","5.11.0-1014.16~20.04.1","5.11.0-1017.19~20.04.1","5.11.0-1018.20~20.04.2","5.11.0-1020.22~20.04.1","5.11.0-1021.23~20.04.1","5.11.0-1022.24~20.04.1","5.11.0-1023.25~20.04.1","5.11.0-1024.26~20.04.1","5.11.0-1026.29~20.04.1","5.11.0-1028.32~20.04.1","5.11.0-1029.33~20.04.3"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gcp-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1008.9~20.04.3","5.13.0-1012.15~20.04.1","5.13.0-1013.16~20.04.1","5.13.0-1015.18~20.04.1","5.13.0-1019.23~20.04.1","5.13.0-1021.25~20.04.1","5.13.0-1023.28~20.04.1","5.13.0-1024.29~20.04.1","5.13.0-1025.30~20.04.1","5.13.0-1027.32~20.04.1","5.13.0-1030.36~20.04.1","5.13.0-1031.37~20.04.1","5.13.0-1033.40~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gcp-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-1032.34~20.04.1","5.8.0-1035.37~20.04.1","5.8.0-1038.40~20.04.1","5.8.0-1039.41"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gke","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1033.35","5.4.0-1035.37","5.4.0-1036.38","5.4.0-1037.39","5.4.0-1039.41","5.4.0-1041.43","5.4.0-1042.44","5.4.0-1043.45","5.4.0-1044.46","5.4.0-1046.48","5.4.0-1049.52","5.4.0-1051.54","5.4.0-1052.55","5.4.0-1053.56","5.4.0-1054.57","5.4.0-1055.58","5.4.0-1056.59","5.4.0-1057.60","5.4.0-1059.62","5.4.0-1061.64","5.4.0-1062.65","5.4.0-1063.66","5.4.0-1065.68","5.4.0-1066.69","5.4.0-1067.70","5.4.0-1068.71","5.4.0-1071.76","5.4.0-1072.77","5.4.0-1074.79","5.4.0-1076.82","5.4.0-1078.84","5.4.0-1080.86","5.4.0-1081.87","5.4.0-1083.89","5.4.0-1084.90","5.4.0-1086.93","5.4.0-1087.94","5.4.0-1090.97","5.4.0-1091.98","5.4.0-1094.101","5.4.0-1095.102","5.4.0-1096.103","5.4.0-1097.104","5.4.0-1098.105","5.4.0-1099.106","5.4.0-1100.107","5.4.0-1101.108","5.4.0-1102.109","5.4.0-1103.110","5.4.0-1104.111","5.4.0-1105.112"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gke-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1011.14~20.04.1","5.15.0-1014.17~20.04.1","5.15.0-1015.18~20.04.1","5.15.0-1016.19~20.04.1","5.15.0-1019.23~20.04.1","5.15.0-1020.25~20.04.1","5.15.0-1023.28~20.04.2","5.15.0-1027.32~20.04.1","5.15.0-1028.33~20.04.1","5.15.0-1029.34~20.04.1","5.15.0-1031.36~20.04.1","5.15.0-1032.37~20.04.1","5.15.0-1033.38~20.04.1","5.15.0-1034.39~20.04.1","5.15.0-1036.41~20.04.1","5.15.0-1037.42~20.04.1","5.15.0-1038.43~20.04.1","5.15.0-1039.44~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gkeop","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1008.9","5.4.0-1009.10","5.4.0-1010.11","5.4.0-1011.12","5.4.0-1012.13","5.4.0-1013.14","5.4.0-1014.15","5.4.0-1015.16","5.4.0-1016.17","5.4.0-1018.19","5.4.0-1021.22","5.4.0-1022.23","5.4.0-1023.24","5.4.0-1024.25","5.4.0-1025.26","5.4.0-1026.27","5.4.0-1027.28","5.4.0-1029.30","5.4.0-1031.32","5.4.0-1032.33","5.4.0-1033.34","5.4.0-1034.35","5.4.0-1036.37","5.4.0-1037.38","5.4.0-1038.39","5.4.0-1039.40","5.4.0-1040.41","5.4.0-1043.44","5.4.0-1046.48","5.4.0-1048.51","5.4.0-1049.52","5.4.0-1051.54","5.4.0-1052.55","5.4.0-1053.56","5.4.0-1054.57","5.4.0-1056.60","5.4.0-1057.61","5.4.0-1060.64","5.4.0-1061.65","5.4.0-1062.66","5.4.0-1064.68","5.4.0-1065.69","5.4.0-1066.70","5.4.0-1067.71","5.4.0-1068.72","5.4.0-1069.73","5.4.0-1070.74","5.4.0-1071.75","5.4.0-1072.76","5.4.0-1073.77","5.4.0-1074.78","5.4.0-1075.79","5.4.0-1076.80","5.4.0-1077.81","5.4.0-1078.82","5.4.0-1079.83","5.4.0-1080.84","5.4.0-1081.85","5.4.0-1083.87","5.4.0-1084.88","5.4.0-1085.89","5.4.0-1086.90","5.4.0-1087.91","5.4.0-1088.92","5.4.0-1089.93","5.4.0-1090.94","5.4.0-1091.95","5.4.0-1092.96","5.4.0-1093.97","5.4.0-1094.98","5.4.0-1095.99","5.4.0-1096.100","5.4.0-1097.101","5.4.0-1098.102","5.4.0-1099.103","5.4.0-1100.104","5.4.0-1101.105","5.4.0-1102.106"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gkeop-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1003.5~20.04.2","5.15.0-1005.7~20.04.1","5.15.0-1007.10~20.04.1","5.15.0-1008.12~20.04.1","5.15.0-1011.15~20.04.2","5.15.0-1012.16~20.04.1","5.15.0-1013.17~20.04.1","5.15.0-1015.19~20.04.1","5.15.0-1016.21~20.04.1","5.15.0-1017.22~20.04.1","5.15.0-1018.23~20.04.1","5.15.0-1019.24~20.04.1","5.15.0-1020.25~20.04.1","5.15.0-1021.26~20.04.1","5.15.0-1022.27~20.04.1","5.15.0-1023.28~20.04.1","5.15.0-1024.29~20.04.1","5.15.0-1025.30~20.04.1","5.15.0-1026.31~20.04.1","5.15.0-1027.32~20.04.1","5.15.0-1028.33~20.04.1","5.15.0-1030.35~20.04.1","5.15.0-1031.37~20.04.1","5.15.0-1032.38~20.04.1","5.15.0-1033.39~20.04.1","5.15.0-1034.40~20.04.1","5.15.0-1035.41~20.04.1","5.15.0-1036.42~20.04.1","5.15.0-1037.43~20.04.1","5.15.0-1038.44~20.04.1","5.15.0-1039.45~20.04.1","5.15.0-1040.46~20.04.1","5.15.0-1043.50~20.04.1","5.15.0-1044.51~20.04.1","5.15.0-1045.52~20.04.1","5.15.0-1046.53~20.04.1","5.15.0-1047.54~20.04.1","5.15.0-1048.55~20.04.1","5.15.0-1049.56~20.04.1","5.15.0-1050.57~20.04.1","5.15.0-1051.58~20.04.1","5.15.0-1052.59~20.04.1","5.15.0-1053.60~20.04.1","5.15.0-1054.61~20.04.1","5.15.0-1055.62~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-hwe-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-22.23~20.04.1","5.11.0-25.27~20.04.1","5.11.0-27.29~20.04.1","5.11.0-34.36~20.04.1","5.11.0-36.40~20.04.1","5.11.0-37.41~20.04.2","5.11.0-38.42~20.04.1","5.11.0-40.44~20.04.2","5.11.0-41.45~20.04.1","5.11.0-43.47~20.04.2","5.11.0-44.48~20.04.2","5.11.0-46.51~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-hwe-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-21.21~20.04.1","5.13.0-22.22~20.04.1","5.13.0-23.23~20.04.2","5.13.0-25.26~20.04.1","5.13.0-27.29~20.04.1","5.13.0-28.31~20.04.1","5.13.0-30.33~20.04.1","5.13.0-35.40~20.04.1","5.13.0-37.42~20.04.1","5.13.0-39.44~20.04.1","5.13.0-40.45~20.04.1","5.13.0-41.46~20.04.1","5.13.0-44.49~20.04.1","5.13.0-48.54~20.04.1","5.13.0-51.58~20.04.1","5.13.0-52.59~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-hwe-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-23.24~20.04.1","5.8.0-25.26~20.04.1","5.8.0-28.30~20.04.1","5.8.0-29.31~20.04.1","5.8.0-31.33~20.04.1","5.8.0-33.36~20.04.1","5.8.0-34.37~20.04.2","5.8.0-36.40~20.04.1","5.8.0-38.43~20.04.1","5.8.0-40.45~20.04.1","5.8.0-41.46~20.04.1","5.8.0-43.49~20.04.1","5.8.0-44.50~20.04.1","5.8.0-45.51~20.04.1","5.8.0-48.54~20.04.1","5.8.0-49.55~20.04.1","5.8.0-50.56~20.04.1","5.8.0-53.60~20.04.1","5.8.0-55.62~20.04.1","5.8.0-59.66~20.04.1","5.8.0-63.71~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-intel-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1007.7","5.13.0-1008.8","5.13.0-1009.9","5.13.0-1010.10","5.13.0-1011.11","5.13.0-1014.15","5.13.0-1017.19"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oem-5.10","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.10.0-1008.9","5.10.0-1011.12","5.10.0-1013.14","5.10.0-1014.15","5.10.0-1016.17","5.10.0-1017.18","5.10.0-1019.20","5.10.0-1021.22","5.10.0-1022.23","5.10.0-1023.24","5.10.0-1025.26","5.10.0-1026.27","5.10.0-1029.30","5.10.0-1032.33","5.10.0-1033.34","5.10.0-1034.35","5.10.0-1038.40","5.10.0-1044.46","5.10.0-1045.47","5.10.0-1049.51","5.10.0-1050.52","5.10.0-1051.53","5.10.0-1052.54","5.10.0-1053.55","5.10.0-1055.58","5.10.0-1057.61"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oem-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1009.10","5.13.0-1010.11","5.13.0-1012.16","5.13.0-1014.18","5.13.0-1017.21","5.13.0-1019.23","5.13.0-1020.24","5.13.0-1021.25","5.13.0-1022.26","5.13.0-1026.32","5.13.0-1028.35","5.13.0-1029.36"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oem-5.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.14.0-1004.4","5.14.0-1005.5","5.14.0-1007.7","5.14.0-1008.8","5.14.0-1010.10","5.14.0-1011.11","5.14.0-1013.13","5.14.0-1018.19","5.14.0-1020.22","5.14.0-1022.24","5.14.0-1024.26","5.14.0-1027.30","5.14.0-1029.32","5.14.0-1031.34","5.14.0-1032.35","5.14.0-1033.36","5.14.0-1034.37","5.14.0-1036.40","5.14.0-1038.42","5.14.0-1042.47","5.14.0-1044.49","5.14.0-1045.51","5.14.0-1046.53","5.14.0-1047.54","5.14.0-1048.55","5.14.0-1049.56","5.14.0-1050.57","5.14.0-1051.58","5.14.0-1052.59","5.14.0-1054.61","5.14.0-1055.62","5.14.0-1056.63","5.14.0-1057.64","5.14.0-1058.66","5.14.0-1059.67"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oem-5.6","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.6.0-1007.7","5.6.0-1008.8","5.6.0-1010.10","5.6.0-1011.11","5.6.0-1013.13","5.6.0-1017.17","5.6.0-1018.18","5.6.0-1020.20","5.6.0-1021.21","5.6.0-1023.23","5.6.0-1026.26","5.6.0-1027.27","5.6.0-1028.28","5.6.0-1031.32","5.6.0-1032.33","5.6.0-1033.35","5.6.0-1034.36","5.6.0-1035.37","5.6.0-1036.39","5.6.0-1039.43","5.6.0-1042.46","5.6.0-1047.51","5.6.0-1048.52","5.6.0-1050.54","5.6.0-1052.56","5.6.0-1053.57","5.6.0-1054.58","5.6.0-1055.59","5.6.0-1056.60"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oracle-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1008.8~20.04.1","5.11.0-1013.14~20.04.1","5.11.0-1016.17~20.04.1","5.11.0-1017.18~20.04.1","5.11.0-1019.20~20.04.1","5.11.0-1020.21~20.04.1","5.11.0-1021.22~20.04.1","5.11.0-1022.23~20.04.1","5.11.0-1023.24~20.04.1","5.11.0-1025.27~20.04.1","5.11.0-1027.30~20.04.1","5.11.0-1028.31~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oracle-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1011.13~20.04.2","5.13.0-1015.19~20.04.1","5.13.0-1016.20~20.04.1","5.13.0-1018.22~20.04.1","5.13.0-1021.26~20.04.1","5.13.0-1025.30~20.04.1","5.13.0-1027.32~20.04.1","5.13.0-1028.33~20.04.1","5.13.0-1030.35~20.04.1","5.13.0-1033.39~20.04.1","5.13.0-1034.40~20.04.1","5.13.0-1036.43~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oracle-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-1031.32~20.04.2","5.8.0-1033.34~20.04.1","5.8.0-1034.35~20.04.2","5.8.0-1037.38~20.04.1","5.8.0-1038.39~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-raspi2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1007.8","5.3.0-1014.16","5.3.0-1015.17","5.3.0-1017.19","5.4.0-1004.4","5.4.0-1006.6"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-riscv","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-24.28","5.4.0-26.30","5.4.0-27.31","5.4.0-28.32","5.4.0-30.34","5.4.0-31.35","5.4.0-33.37","5.4.0-34.38","5.4.0-36.41","5.4.0-37.42","5.4.0-39.44","5.4.0-40.45"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-riscv-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1015.16~20.04.1","5.11.0-1017.18~20.04.1","5.11.0-1018.19~20.04.2","5.11.0-1020.21~20.04.1","5.11.0-1021.22~20.04.1","5.11.0-1022.23~20.04.1","5.11.0-1023.24~20.04.1","5.11.0-1024.25~20.04.1","5.11.0-1026.28~20.04.1","5.11.0-1028.31~20.04.1","5.11.0-1029.32~20.04.1","5.11.0-1030.34","5.11.0-1031.35"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-riscv-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-14.16~20.04.1","5.8.0-14.16~20.04.3","5.8.0-16.18~20.04.1","5.8.0-17.19~20.04.1","5.8.0-18.20~20.04.1","5.8.0-20.22~20.04.1","5.8.0-22.24~20.04.1","5.8.0-25.27~20.04.1","5.8.0-26.28~20.04.1","5.8.0-29.31~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-allwinner-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1007.7~22.04.1","5.19.0-1009.9~22.04.1","5.19.0-1010.10~22.04.1","5.19.0-1011.11~22.04.1","5.19.0-1012.12~22.04.1","5.19.0-1013.13~22.04.1","5.19.0-1014.14~22.04.1","5.19.0-1015.15~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1019.20~22.04.1","5.19.0-1020.21~22.04.1","5.19.0-1022.23~22.04.1","5.19.0-1023.24~22.04.1","5.19.0-1024.25~22.04.1","5.19.0-1025.26~22.04.1","5.19.0-1026.27~22.04.1","5.19.0-1027.28~22.04.1","5.19.0-1028.29~22.04.1","5.19.0-1029.30~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1005.5~22.04.1","6.2.0-1006.6~22.04.1","6.2.0-1007.7~22.04.1","6.2.0-1008.8~22.04.1","6.2.0-1009.9~22.04.3","6.2.0-1010.10~22.04.1","6.2.0-1011.11~22.04.1","6.2.0-1012.12~22.04.1","6.2.0-1013.13~22.04.1","6.2.0-1014.14~22.04.1","6.2.0-1015.15~22.04.1","6.2.0-1016.16~22.04.1","6.2.0-1017.17~22.04.1","6.2.0-1018.18~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1008.8~22.04.1","6.5.0-1010.10~22.04.1","6.5.0-1011.11~22.04.1","6.5.0-1012.12~22.04.1","6.5.0-1014.14~22.04.1","6.5.0-1015.15~22.04.1","6.5.0-1016.16~22.04.1","6.5.0-1017.17~22.04.2","6.5.0-1018.18~22.04.1","6.5.0-1020.20~22.04.1","6.5.0-1021.21~22.04.1","6.5.0-1022.22~22.04.1","6.5.0-1023.23~22.04.1","6.5.0-1024.24~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1018.19~22.04.1"}]}],"versions":["6.8.0-1009.9~22.04.2","6.8.0-1010.10~22.04.2","6.8.0-1011.12~22.04.1","6.8.0-1013.14~22.04.1","6.8.0-1014.15~22.04.1","6.8.0-1015.16~22.04.1","6.8.0-1016.17~22.04.2","6.8.0-1017.18~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1020.21~22.04.1","5.19.0-1021.22~22.04.1","5.19.0-1022.23~22.04.1","5.19.0-1023.24~22.04.1","5.19.0-1025.28~22.04.1","5.19.0-1026.29~22.04.1","5.19.0-1027.30~22.04.2"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1005.5~22.04.1","6.2.0-1006.6~22.04.1","6.2.0-1007.7~22.04.1","6.2.0-1008.8~22.04.1","6.2.0-1009.9~22.04.3","6.2.0-1011.11~22.04.1","6.2.0-1012.12~22.04.1","6.2.0-1014.14~22.04.1","6.2.0-1015.15~22.04.1","6.2.0-1016.16~22.04.1","6.2.0-1017.17~22.04.1","6.2.0-1018.18~22.04.1","6.2.0-1019.19~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1007.7~22.04.1","6.5.0-1009.9~22.04.1","6.5.0-1010.10~22.04.1","6.5.0-1011.11~22.04.1","6.5.0-1015.15~22.04.1","6.5.0-1016.16~22.04.1","6.5.0-1017.17~22.04.1","6.5.0-1018.19~22.04.2","6.5.0-1019.20~22.04.1","6.5.0-1021.22~22.04.1","6.5.0-1022.23~22.04.1","6.5.0-1023.24~22.04.1","6.5.0-1024.25~22.04.1","6.5.0-1025.26~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.20~22.04.1"}]}],"versions":["6.8.0-1008.8~22.04.1","6.8.0-1009.9~22.04.1","6.8.0-1010.10~22.04.1","6.8.0-1012.14~22.04.1","6.8.0-1013.15~22.04.1","6.8.0-1014.16~22.04.1","6.8.0-1015.17~22.04.2"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-fde-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1025.28~22.04.1.1","5.19.0-1026.29~22.04.1.1","5.19.0-1027.30~22.04.2.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-fde-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1008.8~22.04.1.1","6.2.0-1009.9~22.04.3.1","6.2.0-1011.11~22.04.1.1","6.2.0-1012.12~22.04.1.1","6.2.0-1014.14~22.04.1.1","6.2.0-1015.15~22.04.1.1","6.2.0-1016.16~22.04.1.1","6.2.0-1017.17~22.04.1.1","6.2.0-1018.18~22.04.1.1","6.2.0-1019.19~22.04.1.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1020.22~22.04.2","5.19.0-1021.23~22.04.1","5.19.0-1022.24~22.04.1","5.19.0-1024.26~22.04.1","5.19.0-1025.27~22.04.1","5.19.0-1026.28~22.04.1","5.19.0-1027.29~22.04.1","5.19.0-1030.32~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1009.9~22.04.3","6.2.0-1010.10~22.04.1","6.2.0-1011.11~22.04.1","6.2.0-1011.11~22.04.3","6.2.0-1012.12~22.04.1","6.2.0-1013.13~22.04.1","6.2.0-1014.14~22.04.1","6.2.0-1016.18~22.04.1","6.2.0-1017.19~22.04.1","6.2.0-1018.20~22.04.1","6.2.0-1019.21~22.04.1","6.2.0-1021.23~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1010.10~22.04.3","6.5.0-1011.11~22.04.1","6.5.0-1013.13~22.04.1","6.5.0-1014.14~22.04.1","6.5.0-1015.15~22.04.1","6.5.0-1016.16~22.04.1","6.5.0-1017.17~22.04.1","6.5.0-1018.18~22.04.1","6.5.0-1020.20~22.04.1","6.5.0-1022.24~22.04.1","6.5.0-1023.25~22.04.1","6.5.0-1024.26~22.04.1","6.5.0-1025.27~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19~22.04.1"}]}],"versions":["6.8.0-1010.11~22.04.1","6.8.0-1011.12~22.04.1","6.8.0-1012.13~22.04.1","6.8.0-1013.14~22.04.1","6.8.0-1014.16~22.04.1","6.8.0-1015.17~22.04.1","6.8.0-1016.18~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-hwe-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-28.29~22.04.1","5.19.0-32.33~22.04.1","5.19.0-35.36~22.04.1","5.19.0-38.39~22.04.1","5.19.0-40.41~22.04.1","5.19.0-41.42~22.04.1","5.19.0-42.43~22.04.1","5.19.0-43.44~22.04.1","5.19.0-45.46~22.04.1","5.19.0-46.47~22.04.1","5.19.0-50.50"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-hwe-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-25.25~22.04.2","6.2.0-26.26~22.04.1","6.2.0-31.31~22.04.1","6.2.0-32.32~22.04.1","6.2.0-33.33~22.04.1","6.2.0-34.34~22.04.1","6.2.0-35.35~22.04.1","6.2.0-36.37~22.04.1","6.2.0-37.38~22.04.1","6.2.0-39.40~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-hwe-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-14.14~22.04.1","6.5.0-15.15~22.04.1","6.5.0-17.17~22.04.1","6.5.0-18.18~22.04.1","6.5.0-21.21~22.04.1","6.5.0-25.25~22.04.1","6.5.0-26.26~22.04.1","6.5.0-27.28~22.04.1","6.5.0-28.29~22.04.1","6.5.0-35.35~22.04.1","6.5.0-41.41~22.04.2","6.5.0-44.44~22.04.1","6.5.0-45.45~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-hwe-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48~22.04.1"}]}],"versions":["6.8.0-38.38~22.04.1","6.8.0-39.39~22.04.1","6.8.0-40.40~22.04.3","6.8.0-45.45~22.04.1","6.8.0-47.47~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-ibm-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1015.15~22.04.1"}]}],"versions":["6.8.0-1008.8~22.04.1","6.8.0-1010.10~22.04.1","6.8.0-1011.11~22.04.1","6.8.0-1012.12~22.04.1","6.8.0-1013.13~22.04.1","6.8.0-1014.14~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-intel-iot-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1073.75"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1017.18~22.04.1","5.19.0-1018.19~22.04.1","5.19.0-1021.22~22.04.1","5.19.0-1022.23~22.04.1","5.19.0-1023.24~22.04.1","5.19.0-1024.25~22.04.1","5.19.0-1025.26~22.04.1","5.19.0-1027.28~22.04.1","5.19.0-1028.29~22.04.1","5.19.0-1030.30"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1008.8~22.04.1","6.2.0-1009.9~22.04.1","6.2.0-1011.11~22.04.1","6.2.0-1012.12~22.04.1","6.2.0-1013.13~22.04.1","6.2.0-1014.14~22.04.1","6.2.0-1015.15~22.04.1","6.2.0-1016.16~22.04.1","6.2.0-1017.17~22.04.1","6.2.0-1018.18~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-14.14.1~22.04.1","6.5.0-15.15.1.1~22.04.1","6.5.0-17.17.1.1.1~22.04.1","6.5.0-21.21.1~22.04.1","6.5.0-25.25.1~22.04.1","6.5.0-26.26.1~22.04.1","6.5.0-27.28.1~22.04.1","6.5.0-28.29.1~22.04.1","6.5.0-35.35.1~22.04.1","6.5.0-41.41.1~22.04.1","6.5.0-42.42.1~22.04.1","6.5.0-44.44.1~22.04.1","6.5.0-45.45.1~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48.3~22.04.1"}]}],"versions":["6.8.0-38.38.1~22.04.2","6.8.0-40.40.1~22.04.1","6.8.0-44.44.1~22.04.1","6.8.0-45.45.1~22.04.1","6.8.0-47.47.1~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1003.3~22.04.1","6.2.0-1009.9","6.2.0-1010.10","6.2.0-1011.11","6.2.0-1012.12","6.2.0-1013.13","6.2.0-1015.15"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1004.4","6.5.0-1007.7","6.5.0-1013.13","6.5.0-1014.14","6.5.0-1015.15","6.5.0-1018.18","6.5.0-1019.19","6.5.0-1021.22","6.5.0-1022.23","6.5.0-1023.24","6.5.0-1024.25"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19~22.04.1"}]}],"versions":["6.8.0-1008.8~22.04.1","6.8.0-1009.9~22.04.1","6.8.0-1010.10~22.04.1","6.8.0-1011.11~22.04.1","6.8.0-1012.12~22.04.1","6.8.0-1013.14~22.04.1","6.8.0-1014.15~22.04.1","6.8.0-1015.16~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oem-5.17","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.17.0-1003.3","5.17.0-1004.4","5.17.0-1006.6","5.17.0-1011.12","5.17.0-1012.13","5.17.0-1013.14","5.17.0-1014.15","5.17.0-1015.16","5.17.0-1016.17","5.17.0-1017.18","5.17.0-1018.19","5.17.0-1019.20","5.17.0-1020.21","5.17.0-1021.22","5.17.0-1024.25","5.17.0-1025.26","5.17.0-1026.27","5.17.0-1027.28","5.17.0-1028.29","5.17.0-1029.30","5.17.0-1030.31","5.17.0-1031.32","5.17.0-1032.33","5.17.0-1033.34","5.17.0-1034.35","5.17.0-1035.36"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oem-6.0","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.0.0-1006.6","6.0.0-1007.7","6.0.0-1008.8","6.0.0-1009.9","6.0.0-1010.10","6.0.0-1011.11","6.0.0-1012.12","6.0.0-1013.13","6.0.0-1014.14","6.0.0-1015.15","6.0.0-1016.16","6.0.0-1017.17","6.0.0-1018.18","6.0.0-1019.19","6.0.0-1020.20","6.0.0-1021.21"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oem-6.1","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.1.0-1004.4","6.1.0-1006.6","6.1.0-1007.7","6.1.0-1008.8","6.1.0-1009.9","6.1.0-1010.10","6.1.0-1012.12","6.1.0-1013.13","6.1.0-1014.14","6.1.0-1015.15","6.1.0-1016.16","6.1.0-1017.17","6.1.0-1019.19","6.1.0-1020.20","6.1.0-1021.21","6.1.0-1022.22","6.1.0-1023.23","6.1.0-1024.24","6.1.0-1025.25","6.1.0-1026.26","6.1.0-1027.27","6.1.0-1028.28","6.1.0-1029.29","6.1.0-1033.33","6.1.0-1034.34","6.1.0-1035.35","6.1.0-1036.36"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oem-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1003.3","6.5.0-1004.4","6.5.0-1006.6","6.5.0-1007.7","6.5.0-1008.8","6.5.0-1009.10","6.5.0-1011.12","6.5.0-1013.14","6.5.0-1014.15","6.5.0-1015.16","6.5.0-1016.17","6.5.0-1018.19","6.5.0-1019.20","6.5.0-1020.21","6.5.0-1022.23","6.5.0-1023.24","6.5.0-1024.25","6.5.0-1025.26","6.5.0-1027.28"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oracle-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1013.13~22.04.4","6.5.0-1014.14~22.04.1","6.5.0-1015.15~22.04.1","6.5.0-1016.16~22.04.1","6.5.0-1018.18~22.04.1","6.5.0-1019.19~22.04.1","6.5.0-1020.20~22.04.1","6.5.0-1021.21~22.04.1","6.5.0-1023.23~22.04.1","6.5.0-1024.24~22.04.1","6.5.0-1025.25~22.04.1","6.5.0-1026.26~22.04.1","6.5.0-1027.27~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oracle-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1015.15~22.04.1"}]}],"versions":["6.8.0-1006.6~22.04.3","6.8.0-1008.8~22.04.1","6.8.0-1010.10~22.04.1","6.8.0-1011.11~22.04.1","6.8.0-1012.12~22.04.1","6.8.0-1013.13~22.04.1","6.8.0-1014.14~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1032.35"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-riscv","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1004.4","5.13.0-1006.6+22.04.1","5.13.0-1007.7+22.04.1","5.13.0-1010.11+22.04.1","5.15.0-1004.4","5.15.0-1005.5","5.15.0-1006.6","5.15.0-1007.7","5.15.0-1008.8","5.15.0-1011.12","5.15.0-1012.13","5.15.0-1014.16","5.15.0-1015.17","5.15.0-1016.18","5.15.0-1017.19","5.15.0-1018.21","5.15.0-1019.22","5.15.0-1020.23","5.15.0-1022.26","5.15.0-1023.27","5.15.0-1026.30","5.15.0-1027.31","5.15.0-1028.32"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-riscv-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1012.13~22.04.1","5.19.0-1015.16~22.04.1","5.19.0-1016.17~22.04.1","5.19.0-1017.18~22.04.1","5.19.0-1018.19~22.04.1","5.19.0-1019.21~22.04.1","5.19.0-1020.22~22.04.1","5.19.0-1021.23~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-riscv-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-17.17.1.1~22.04.1","6.5.0-21.21.1~22.04.1","6.5.0-25.25.1~22.04.1","6.5.0-26.26.1~22.04.1","6.5.0-27.28.1~22.04.1","6.5.0-28.29.1~22.04.1","6.5.0-35.35.1~22.04.1","6.5.0-40.40.1~22.04.1","6.5.0-42.42.1~22.04.1","6.5.0-45.45.1~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-riscv-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48.1~22.04.2"}]}],"versions":["6.8.0-38.38.1~22.04.1","6.8.0-39.39.1~22.04.1","6.8.0-40.40.1~22.04.1","6.8.0-41.41.1~22.04.1","6.8.0-44.44.1~22.04.1","6.8.0-47.47.1~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-starfive-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1014.16~22.04.1","5.19.0-1015.17~22.04.1","5.19.0-1016.18~22.04.1","5.19.0-1017.19~22.04.1","5.19.0-1018.20~22.04.1","5.19.0-1019.21~22.04.1","5.19.0-1020.22~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-starfive-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1006.7~22.04.1","6.2.0-1007.8~22.04.1","6.2.0-1009.10~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-starfive-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1007.8~22.04.1","6.5.0-1008.9~22.04.1","6.5.0-1009.10~22.04.1","6.5.0-1010.11~22.04.1","6.5.0-1011.12~22.04.1","6.5.0-1012.13~22.04.1","6.5.0-1014.15~22.04.1","6.5.0-1015.16~22.04.1","6.5.0-1016.17~22.04.1","6.5.0-1017.18~22.04.1","6.5.0-1018.19~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:22.04:LTS","package":"linux-realtime-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.1-1011.11~22.04.1"}]}],"versions":["6.8.1-1004.4~22.04.1","6.8.1-1005.5~22.04.2","6.8.1-1006.6~22.04.1","6.8.1-1007.7~22.04.1","6.8.1-1008.8~22.04.1","6.8.1-1009.9~22.04.1","6.8.1-1010.10~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48"}]}],"versions":["6.5.0-9.9","6.6.0-14.14","6.8.0-11.11","6.8.0-20.20","6.8.0-22.22","6.8.0-28.28","6.8.0-31.31","6.8.0-35.35","6.8.0-36.36","6.8.0-38.38","6.8.0-39.39","6.8.0-40.40","6.8.0-41.41","6.8.0-44.44","6.8.0-45.45","6.8.0-47.47"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-aws","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1018.20"}]}],"versions":["6.5.0-1008.8","6.6.0-1001.1","6.8.0-1001.1","6.8.0-1006.6","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1011.12","6.8.0-1012.13","6.8.0-1013.14","6.8.0-1014.15","6.8.0-1015.16","6.8.0-1016.17","6.8.0-1017.18"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.20"}]}],"versions":["6.5.0-1007.7","6.6.0-1001.1","6.8.0-1001.1","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1012.14","6.8.0-1013.15","6.8.0-1014.16","6.8.0-1015.17","6.8.0-1016.18"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19"}]}],"versions":["6.5.0-1007.7","6.6.0-1001.1","6.8.0-1002.2","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.9","6.8.0-1009.10","6.8.0-1010.11","6.8.0-1011.12","6.8.0-1012.13","6.8.0-1013.14","6.8.0-1014.16","6.8.0-1015.17","6.8.0-1016.18"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gke","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1013.17"}]}],"versions":["6.8.0-1003.5","6.8.0-1004.7","6.8.0-1005.8","6.8.0-1006.9","6.8.0-1007.10","6.8.0-1008.11","6.8.0-1009.12","6.8.0-1010.13","6.8.0-1011.14","6.8.0-1012.15"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gkeop","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1002.4"}]}],"versions":["6.8.0-1001.3"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-ibm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1015.15"}]}],"versions":["6.5.0-1009.9","6.8.0-1001.1","6.8.0-1003.3","6.8.0-1004.4","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1011.11","6.8.0-1012.12","6.8.0-1013.13","6.8.0-1014.14"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48.3"}]}],"versions":["6.5.0-9.9.1","6.6.0-14.14.1","6.8.0-7.7.1","6.8.0-25.25.3","6.8.0-28.28.1","6.8.0-31.31.1","6.8.0-35.35.1","6.8.0-36.36.1","6.8.0-38.38.1","6.8.0-39.39.1","6.8.0-40.40.1","6.8.0-41.41.1","6.8.0-44.44.1","6.8.0-45.45.1","6.8.0-47.47.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19"}]}],"versions":["6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1011.11","6.8.0-1012.12","6.8.0-1013.14","6.8.0-1014.15","6.8.0-1015.16"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19.1"}]}],"versions":["6.8.0-1009.9.1","6.8.0-1011.11.1","6.8.0-1012.12.1","6.8.0-1013.14.1","6.8.0-1014.15.1","6.8.0-1015.16.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1016.16"}]}],"versions":["6.8.0-1003.3","6.8.0-1004.4","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1011.11","6.8.0-1012.12","6.8.0-1013.13","6.8.0-1014.14"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oracle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1015.16"}]}],"versions":["6.5.0-1010.10","6.6.0-1001.1","6.8.0-1001.1","6.8.0-1004.4","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1008.8","6.8.0-1010.10","6.8.0-1011.11","6.8.0-1012.12","6.8.0-1013.13","6.8.0-1014.14"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-raspi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1014.16"}]}],"versions":["6.5.0-1005.7","6.7.0-1001.1","6.8.0-1001.1","6.8.0-1002.2","6.8.0-1003.3","6.8.0-1004.4","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.10","6.8.0-1010.11","6.8.0-1011.12","6.8.0-1012.13","6.8.0-1013.14"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-riscv","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48.1"}]}],"versions":["6.5.0-9.9.1","6.8.0-20.20.1","6.8.0-28.28.1","6.8.0-31.31.1","6.8.0-35.35.1","6.8.0-36.36.1","6.8.0-38.38.1","6.8.0-39.39.1","6.8.0-40.40.1","6.8.0-41.41.1","6.8.0-44.44.1","6.8.0-47.47.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-xilinx","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1009.10"}]}],"versions":["6.8.0-1008.9"]},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-raspi-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-2013.14"}]}],"versions":["6.7.0-2001.1","6.8.0-2001.1","6.8.0-2002.2","6.8.0-2004.4","6.8.0-2005.5","6.8.0-2006.6","6.8.0-2007.7","6.8.0-2008.8","6.8.0-2009.9","6.8.0-2010.10","6.8.0-2011.11","6.8.0-2012.12"]},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.1-1011.11"}]}],"versions":["6.8.0-1008.19","6.8.1-1001.1","6.8.1-1002.2","6.8.1-1003.3","6.8.1-1004.4","6.8.1-1005.5","6.8.1-1006.6","6.8.1-1007.7","6.8.1-1008.8","6.8.1-1009.9","6.8.1-1010.10"]},{"source":"osv","ecosystem":"Ubuntu:Pro:FIPS-updates:24.04:LTS","package":"linux-fips","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-78.78+fips1"}]}],"versions":["6.8.0-38.38+fips4"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19~22.04.1"}]}],"versions":["6.8.0-1010.11~22.04.1","6.8.0-1011.12~22.04.1","6.8.0-1012.13~22.04.1","6.8.0-1013.14~22.04.1","6.8.0-1014.16~22.04.1","6.8.0-1015.17~22.04.1","6.8.0-1016.18~22.04.1"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-hwe-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48~22.04.1"}]}],"versions":["6.8.0-38.38~22.04.1","6.8.0-39.39~22.04.1","6.8.0-40.40~22.04.3","6.8.0-45.45~22.04.1","6.8.0-47.47~22.04.1"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48"}]}],"versions":["6.5.0-9.9","6.6.0-14.14","6.8.0-11.11","6.8.0-20.20","6.8.0-22.22","6.8.0-28.28","6.8.0-31.31","6.8.0-35.35","6.8.0-36.36","6.8.0-38.38","6.8.0-39.39","6.8.0-40.40","6.8.0-41.41","6.8.0-44.44","6.8.0-45.45","6.8.0-47.47"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.20"}]}],"versions":["6.5.0-1007.7","6.6.0-1001.1","6.8.0-1001.1","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1012.14","6.8.0-1013.15","6.8.0-1014.16","6.8.0-1015.17","6.8.0-1016.18"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19"}]}],"versions":["6.5.0-1007.7","6.6.0-1001.1","6.8.0-1002.2","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.9","6.8.0-1009.10","6.8.0-1010.11","6.8.0-1011.12","6.8.0-1012.13","6.8.0-1013.14","6.8.0-1014.16","6.8.0-1015.17","6.8.0-1016.18"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-ibm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1015.15"}]}],"versions":["6.5.0-1009.9","6.8.0-1001.1","6.8.0-1003.3","6.8.0-1004.4","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1011.11","6.8.0-1012.12","6.8.0-1013.13","6.8.0-1014.14"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1018.19~22.04.1"}]}],"versions":["6.8.0-1009.9~22.04.2","6.8.0-1010.10~22.04.2","6.8.0-1011.12~22.04.1","6.8.0-1013.14~22.04.1","6.8.0-1014.15~22.04.1","6.8.0-1015.16~22.04.1","6.8.0-1016.17~22.04.2","6.8.0-1017.18~22.04.1"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oracle-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1015.15~22.04.1"}]}],"versions":["6.8.0-1006.6~22.04.3","6.8.0-1008.8~22.04.1","6.8.0-1010.10~22.04.1","6.8.0-1011.11~22.04.1","6.8.0-1012.12~22.04.1","6.8.0-1013.13~22.04.1","6.8.0-1014.14~22.04.1"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-aws","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1018.20"}]}],"versions":["6.5.0-1008.8","6.6.0-1001.1","6.8.0-1001.1","6.8.0-1006.6","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1011.12","6.8.0-1012.13","6.8.0-1013.14","6.8.0-1014.15","6.8.0-1015.16","6.8.0-1016.17","6.8.0-1017.18"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oracle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1015.16"}]}],"versions":["6.5.0-1010.10","6.6.0-1001.1","6.8.0-1001.1","6.8.0-1004.4","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1008.8","6.8.0-1010.10","6.8.0-1011.11","6.8.0-1012.12","6.8.0-1013.13","6.8.0-1014.14"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1016.16"}]}],"versions":["6.8.0-1003.3","6.8.0-1004.4","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1011.11","6.8.0-1012.12","6.8.0-1013.13","6.8.0-1014.14"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-raspi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1014.16"}]}],"versions":["6.5.0-1005.7","6.7.0-1001.1","6.8.0-1001.1","6.8.0-1002.2","6.8.0-1003.3","6.8.0-1004.4","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.10","6.8.0-1010.11","6.8.0-1011.12","6.8.0-1012.13","6.8.0-1013.14"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gke","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1013.17"}]}],"versions":["6.8.0-1003.5","6.8.0-1004.7","6.8.0-1005.8","6.8.0-1006.9","6.8.0-1007.10","6.8.0-1008.11","6.8.0-1009.12","6.8.0-1010.13","6.8.0-1011.14","6.8.0-1012.15"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48.3~22.04.1"}]}],"versions":["6.8.0-38.38.1~22.04.2","6.8.0-40.40.1~22.04.1","6.8.0-44.44.1~22.04.1","6.8.0-45.45.1~22.04.1","6.8.0-47.47.1~22.04.1"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-48.48.3"}]}],"versions":["6.5.0-9.9.1","6.6.0-14.14.1","6.8.0-7.7.1","6.8.0-25.25.3","6.8.0-28.28.1","6.8.0-31.31.1","6.8.0-35.35.1","6.8.0-36.36.1","6.8.0-38.38.1","6.8.0-39.39.1","6.8.0-40.40.1","6.8.0-41.41.1","6.8.0-44.44.1","6.8.0-45.45.1","6.8.0-47.47.1"],"bundled":196},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.20~22.04.1"}]}],"versions":["6.8.0-1008.8~22.04.1","6.8.0-1009.9~22.04.1","6.8.0-1010.10~22.04.1","6.8.0-1012.14~22.04.1","6.8.0-1013.15~22.04.1","6.8.0-1014.16~22.04.1","6.8.0-1015.17~22.04.2"],"bundled":198},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19~22.04.1"}]}],"versions":["6.8.0-1008.8~22.04.1","6.8.0-1009.9~22.04.1","6.8.0-1010.10~22.04.1","6.8.0-1011.11~22.04.1","6.8.0-1012.12~22.04.1","6.8.0-1013.14~22.04.1","6.8.0-1014.15~22.04.1","6.8.0-1015.16~22.04.1"],"bundled":197},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19"}]}],"versions":["6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1011.11","6.8.0-1012.12","6.8.0-1013.14","6.8.0-1014.15","6.8.0-1015.16"],"bundled":197},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1017.19.1"}]}],"versions":["6.8.0-1009.9.1","6.8.0-1011.11.1","6.8.0-1012.12.1","6.8.0-1013.14.1","6.8.0-1014.15.1","6.8.0-1015.16.1"],"bundled":197},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gkeop","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1002.4"}]}],"versions":["6.8.0-1001.3"],"bundled":607}],"products":[{"vendor":"linux","product":"linux"},{"vendor":"linux","product":"linux_kernel"}],"references":[{"url":"https://git.kernel.org/stable/c/c20d0fa873039bce82d4b1b2ffcda8bb22242790","tags":["web"]},{"url":"https://git.kernel.org/stable/c/044da7ae7afd4ef60806d73654a2e6a79aa4ed7a","tags":["x_transferred","Patch","web","report"]},{"url":"https://git.kernel.org/stable/c/e60adf513275c3a38e5cb67f7fd12387e43a3ff5","tags":["x_transferred","Patch","web","report"]},{"url":"https://git.kernel.org/stable/c/08f6c05feb1db21653e98ca84ea04ca032d014c7","tags":["x_transferred","Patch","web","report"]},{"url":"https://git.kernel.org/stable/c/9fef36cad60d4226f9d06953cd56d1d2f9119730","tags":["x_transferred","Patch","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42067","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-x8rh-6x6w-x2xg"},{"url":"https://docs.bell-sw.com/security/cves/CVE-2024-42067","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/42xxx/CVE-2024-42067.json","tags":["advisory"]},{"url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","tags":["package"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2024-42067","tags":["advisory"]},{"url":"https://advisories.mageia.org/MGASA-2024-0277.html","tags":["advisory"]},{"url":"https://bugs.mageia.org/show_bug.cgi?id=33446","tags":["report"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.38","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.39","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.40","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.41","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.42","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.43","tags":["web"]},{"url":"https://advisories.mageia.org/MGASA-2024-0278.html","tags":["advisory"]},{"url":"https://bugs.mageia.org/show_bug.cgi?id=33447","tags":["report"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2219","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42312","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44949","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44958","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45009","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45011","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45016","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45028","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45029","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46673","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46674","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46679","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46681","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46686","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46695","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46701","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46717","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46721","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46722","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46725","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46728","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46732","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46734","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46736","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46737","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46738","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46739","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46740","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46750","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46753","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46755","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46756","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46758","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46760","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46761","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46767","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46768","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46771","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46772","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46773","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46776","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46777","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46780","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46781","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46784","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46787","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46788","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46791","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46796","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46797","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46798","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46804","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46806","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46811","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46812","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46814","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46816","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46818","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46827","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46829","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46841","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46842","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46843","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46844","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46845","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46846","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46849","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46852","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46857","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2255","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48893","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52444","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52463","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52482","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52612","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52843","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26820","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36005","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40998","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42283","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42290","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42306","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42309","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42313","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42322","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43823","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43830","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43840","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43855","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43872","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43892","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43893","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44940","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44954","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44998","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45006","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45026","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46676","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46719","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46754","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46770","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46795","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46819","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46826","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46828","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46840","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46848","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46854","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46855","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46858","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47658","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47664","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47670","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47671","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47672","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2257","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48688","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48848","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48869","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48879","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48945","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-0597","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-4134","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52707","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52741","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52880","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36031","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2258","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47382","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35825","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35969","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36270","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36880","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36915","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36934","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36946","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38546","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38560","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38611","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38613","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38659","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39292","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39494","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40932","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40988","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41019","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41040","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41041","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41048","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41049","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41063","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41069","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41080","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41090","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41091","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42086","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42097","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42115","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42129","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42228","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2024-42067","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-42067","tags":["report"]},{"url":"https://git.kernel.org/linus/e60adf513275c3a38e5cb67f7fd12387e43a3ff5","tags":["report"]},{"url":"https://ubuntu.com/security/notices/USN-7089-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7090-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7089-2","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7089-3","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7095-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7089-4","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7089-5","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7089-6","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7089-7","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7156-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2023-52887","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52888","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-25741","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39486","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39487","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41007","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41010","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41012","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41015","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41017","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41018","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41019","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41020","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41021","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41022","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41023","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41025","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41027","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41028","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41029","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41030","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41031","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41032","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41033","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41034","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41035","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41036","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41037","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41038","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41039","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41041","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41042","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41044","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41045","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41046","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41047","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41048","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41049","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41050","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41051","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41052","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41053","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41054","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41055","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41056","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41057","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41058","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41059","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41060","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41061","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41062","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41063","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41064","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41065","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41066","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41067","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41068","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41069","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41070","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41071","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41072","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41073","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41074","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41075","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41076","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41077","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41078","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41079","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41080","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41081","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41082","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41083","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41084","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41085","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41086","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41087","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41088","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41089","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41090","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41091","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41092","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41093","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41094","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41095","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41096","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41097","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41098","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42063","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42064","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42065","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42066","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42068","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42069","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42070","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42073","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42074","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42076","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42077","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42079","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42080","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42082","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42084","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42085","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42086","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42087","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42088","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42089","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42090","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42091","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42092","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42093","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42094","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42095","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42096","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42097","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42098","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42100","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42101","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42102","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42103","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42104","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42105","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42106","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42108","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42109","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42110","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42111","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42112","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42113","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42114","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42115","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42117","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42118","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42119","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42120","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42121","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42124","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42126","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42127","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42128","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42129","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42130","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42131","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42132","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42133","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42135","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42136","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42137","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42138","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42140","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42141","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42142","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42144","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42145","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42146","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42147","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42149","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42150","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42151","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42152","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42153","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42155","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42156","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42157","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42158","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42161","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42223","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42225","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42227","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42229","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42230","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42231","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42232","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42234","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42235","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42236","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42237","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42238","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42239","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42240","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42241","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42243","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42244","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42245","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42246","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42247","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42248","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42250","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42251","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42252","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42253","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42271","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42280","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43855","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43858","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45001","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45016","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52889","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52918","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-27022","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39472","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41009","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42154","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42159","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42160","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42224","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42228","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42258","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42259","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42260","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42261","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42262","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42263","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42264","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42265","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42267","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42268","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42269","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42270","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42272","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42273","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42274","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42276","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42277","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42278","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42279","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42281","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42283","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42284","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42285","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42286","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42287","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42288","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42289","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42290","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42291","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42292","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42294","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42295","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42296","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42297","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42298","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42299","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42301","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42302","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42303","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42304","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42305","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42306","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42307","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42309","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42310","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42311","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42312","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42313","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42314","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42315","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42316","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42317","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42318","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42319","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42320","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42321","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42322","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43817","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43818","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43819","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43820","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43821","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43823","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43824","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43825","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43826","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43827","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43828","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43829","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43830","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43831","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43832","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43833","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43834","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43835","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43837","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43839","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43840","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43841","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43842","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43843","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43845","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43846","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43847","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43849","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43850","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43852","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43853","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43854","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43856","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43857","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43859","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43860","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43861","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43863","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43864","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43866","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43867","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43868","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43869","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43870","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43871","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43873","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43875","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43876","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43877","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43879","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43880","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43881","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43882","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43883","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43884","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43886","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43887","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43888","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43889","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43890","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43891","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43892","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43893","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43894","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43895","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43899","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43900","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43902","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43904","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43905","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43906","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43907","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43908","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43909","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43910","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43911","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43912","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43913","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43914","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44931","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44934","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44935","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44937","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44938","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44939","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44940","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44941","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44942","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44943","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44944","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44946","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44947","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44948","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44950","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44953","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44954","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44956","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44957","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44958","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44959","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44960","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44961","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44962","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44963","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44965","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44966","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44967","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44969","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44970","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44971","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44972","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44973","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44974","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44975","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44977","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44978","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44979","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44980","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44982","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44983","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44984","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44985","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44986","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44987","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44988","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44989","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44990","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44991","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44993","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44995","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44996","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44998","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44999","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45000","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45002","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45003","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45005","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45006","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45007","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45008","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45009","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45010","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45011","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45012","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45013","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45015","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45017","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45018","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45019","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45020","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45021","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45022","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45025","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45026","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45027","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45028","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45029","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45030","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46672","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46673","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46675","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46676","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46677","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46678","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46679","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46680","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46681","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46683","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46685","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46686","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46687","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46689","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46691","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46692","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46693","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46694","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46695","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46697","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46698","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46701","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46702","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46703","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46705","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46706","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46707","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46708","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46709","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46710","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46711","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46713","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46714","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46715","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46716","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46717","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46718","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46719","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46720","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46721","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46722","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46723","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46724","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46725","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46726","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46727","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46728","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46729","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46730","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46731","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46732","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46733","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46735","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46737","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46738","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46739","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46740","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46741","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46743","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46744","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46745","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46746","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46747","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46749","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46750","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46751","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46752","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46753","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46754","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46755","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46756","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46757","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46758","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46759","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46760","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46761","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46762","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46763","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46765","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46766","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46767","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46768","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46770","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46771","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46772","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46773","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46774","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46775","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46776","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46777","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46778","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46779","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46780","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46781","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46782","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46783","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46784","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46785","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46786","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46787","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46788","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46791","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46792","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46793","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46794","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46795","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46797","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46798","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46800","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46802","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46803","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46804","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46805","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46806","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46807","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46808","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46809","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46810","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46811","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46812","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46813","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46814","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46815","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46816","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46817","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46818","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46819","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46821","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46822","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46823","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46824","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46825","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46826","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46827","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46828","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46829","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46830","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46831","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46832","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46834","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46835","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46836","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46838","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46840","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46841","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46842","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46843","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46844","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46845","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46846","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46848","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46849","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46850","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46851","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46852","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46853","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46854","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46855","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46857","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46858","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46859","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46860","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46861","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46864","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46866","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46867","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46868","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46870","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46871","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47658","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47659","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47660","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47661","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47662","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47663","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47664","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47665","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47666","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47667","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47668","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47669","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47674","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47683","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49984","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2024-42067","title":"bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\n\nset_memory_rox() can fail, leaving memory unprotected.\n\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.","status":"published","published":"2024-07-29T15:52:31.825Z","modified":"2026-10-21T12:34:57.072Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"cna"}],"updated_at":"2026-11-02T14:34:03.333404Z"}],"euvd":[{"id":"EUVD-2024-39899","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\n\nset_memory_rox() can fail, leaving memory unprotected.\n\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.","status":"published","published":"2024-07-29T15:52:31Z","modified":"2026-10-21T12:34:57Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T16:59:39.717973Z"}],"ghsa":[{"id":"GHSA-x8rh-6x6w-x2xg","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Take return from...","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\n\nset_memory_rox() can fail, leaving memory unprotected.\n\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.","status":"published","published":"2024-07-29T18:30:39Z","modified":"2026-10-21T15:41:02Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-252"],"updated_at":"2026-11-02T15:14:10.227394Z"}],"nvd":[{"id":"CVE-2024-42067","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\n\nset_memory_rox() can fail, leaving memory unprotected.\n\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.","status":"published","published":"2024-07-29T16:15:06.323Z","modified":"2026-10-21T13:17:45.39Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"secondary"},{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"primary"}],"cwes":["CWE-252"],"updated_at":"2026-11-02T14:10:14.437386Z"}],"osv":[{"id":"AZL-47137","title":"CVE-2024-42067 affecting package kernel 5.15.200.1-1","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\n\nset_memory_rox() can fail, leaving memory unprotected.\n\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.","status":"published","published":"2024-07-29T16:15:06Z","modified":"2026-04-21T04:32:50.069602Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:28:05.694722Z"},{"id":"AZL-47157","title":"CVE-2024-42067 affecting package kernel for versions less than 6.6.43.1-7","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\n\nset_memory_rox() can fail, leaving memory unprotected.\n\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.","status":"published","published":"2024-07-29T16:15:06Z","modified":"2026-11-04T15:04:39Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-05T16:41:20.321068Z"},{"id":"BELL-CVE-2024-42067","status":"published","published":"2024-07-31T05:58:54.7537Z","modified":"2026-01-26T09:35:04.506991Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:28:20.200735Z"},{"id":"CVE-2024-42067","title":"bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\n\nset_memory_rox() can fail, leaving memory unprotected.\n\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.","status":"published","published":"2024-07-29T15:52:31.825Z","modified":"2026-10-28T02:30:34.306579883Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:44:41.963899Z"},{"id":"DEBIAN-CVE-2024-42067","description":"In the Linux kernel, the following vulnerability has been resolved:  bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()  set_memory_rox() can fail, leaving memory unprotected.  Check return and bail out when bpf_jit_binary_lock_ro() returns an error.","status":"published","published":"2024-07-29T16:15:06.323Z","modified":"2026-11-02T12:02:59.042310056Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:45:43.156294Z"},{"id":"OESA-2024-2219","title":"kernel security update","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\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\r\n\r\nset_memory_rox() can fail, leaving memory unprotected.\r\n\r\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.(CVE-2024-42067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysctl: always initialize i_uid/i_gid\r\n\r\nAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()\ncan safely skip setting them.\r\n\r\nCommit 5ec27ec735ba (\u0026quot;fs/proc/proc_sysctl.c: fix the default values of\ni_uid/i_gid on /proc/sys inodes.\u0026quot;) added defaults for i_uid/i_gid when\nset_ownership() was not implemented. It also missed adjusting\nnet_ctl_set_ownership() to use the same default values in case the\ncomputation of a better value failed.(CVE-2024-42312)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nparisc: fix a possible DMA corruption\r\n\r\nARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be\npossible that two unrelated 16-byte allocations share a cache line. If\none of these allocations is written using DMA and the other is written\nusing cached write, the value that was written with DMA may be\ncorrupted.\r\n\r\nThis commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -\nthat\u0026apos;s the largest possible cache line size.\r\n\r\nAs different parisc microarchitectures have different cache line size, we\ndefine arch_slab_minalign(), cache_line_size() and\ndma_get_cache_alignment() so that the kernel may tune slab cache\nparameters dynamically, based on the detected cache line size.(CVE-2024-44949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/smt: Fix unbalance sched_smt_present dec/inc\r\n\r\nI got the following warn report while doing stress test:\r\n\r\njump label: negative count!\nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked+0x16/0x70\n sched_cpu_deactivate+0x26e/0x2a0\n cpuhp_invoke_callback+0x3ad/0x10d0\n cpuhp_thread_fun+0x3f5/0x680\n smpboot_thread_fn+0x56d/0x8d0\n kthread+0x309/0x400\n ret_from_fork+0x41/0x70\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),\nthe cpu offline failed, but sched_smt_present is decremented before\ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so\nfix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: only decrement add_addr_accepted for MPJ req\r\n\r\nAdding the following warning ...\r\n\r\n  WARN_ON_ONCE(msk-\u0026gt;pm.add_addr_accepted == 0)\r\n\r\n... before decrementing the add_addr_accepted counter helped to find a\nbug when running the \u0026quot;remove single subflow\u0026quot; subtest from the\nmptcp_join.sh selftest.\r\n\r\nRemoving a \u0026apos;subflow\u0026apos; endpoint will first trigger a RM_ADDR, then the\nsubflow closure. Before this patch, and upon the reception of the\nRM_ADDR, the other peer will then try to decrement this\nadd_addr_accepted. That\u0026apos;s not correct because the attached subflows have\nnot been created upon the reception of an ADD_ADDR.\r\n\r\nA way to solve that is to decrement the counter only if the attached\nsubflow was an MP_JOIN to a remote id that was not 0, and initiated by\nthe host receiving the RM_ADDR.(CVE-2024-45009)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nchar: xillybus: Check USB endpoints when probing device\r\n\r\nEnsure, as the driver probes the device, that all endpoints that the\ndriver may attempt to access exist and are of the correct type.\r\n\r\nAll XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at\naddress 1. This is verified in xillyusb_setup_base_eps().\r\n\r\nOn top of that, a XillyUSB device may have additional Bulk OUT\nendpoints. The information about these endpoints\u0026apos; addresses is deduced\nfrom a data structure (the IDT) that the driver fetches from the device\nwhile probing it. These endpoints are checked in setup_channels().\r\n\r\nA XillyUSB device never has more than one IN endpoint, as all data\ntowards the host is multiplexed in this single Bulk IN endpoint. This is\nwhy setup_channels() only checks OUT endpoints.(CVE-2024-45011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetem: fix return value if duplicate enqueue fails\r\n\r\nThere is a bug in netem_enqueue() introduced by\ncommit 5845f706388a (\u0026quot;net: netem: fix skb length BUG_ON in __skb_to_sgvec\u0026quot;)\nthat can lead to a use-after-free.\r\n\r\nThis commit made netem_enqueue() always return NET_XMIT_SUCCESS\nwhen a packet is duplicated, which can cause the parent qdisc\u0026apos;s q.qlen\nto be mistakenly incremented. When this happens qlen_notify() may be\nskipped on the parent during destruction, leaving a dangling pointer\nfor some classful qdiscs like DRR.\r\n\r\nThere are two ways for the bug happen:\r\n\r\n- If the duplicated packet is dropped by rootq-\u0026gt;enqueue() and then\n  the original packet is also dropped.\n- If rootq-\u0026gt;enqueue() sends the duplicated packet to a different qdisc\n  and the original packet is dropped.\r\n\r\nIn both cases NET_XMIT_SUCCESS is returned even though no packets\nare enqueued at the netem qdisc.\r\n\r\nThe fix is to defer the enqueue of the duplicate packet until after\nthe original packet has been guaranteed to return NET_XMIT_SUCCESS.(CVE-2024-45016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_test: Fix NULL dereference on allocation failure\r\n\r\nIf the \u0026quot;test-\u0026gt;highmem = alloc_pages()\u0026quot; allocation fails then calling\n__free_pages(test-\u0026gt;highmem) will result in a NULL dereference.  Also\nchange the error code to -ENOMEM instead of returning success.(CVE-2024-45028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: tegra: Do not mark ACPI devices as irq safe\r\n\r\nOn ACPI machines, the tegra i2c module encounters an issue due to a\nmutex being called inside a spinlock. This leads to the following bug:\r\n\r\n\tBUG: sleeping function called from invalid context at kernel/locking/mutex.c:585\n\t...\r\n\r\n\tCall trace:\n\t__might_sleep\n\t__mutex_lock_common\n\tmutex_lock_nested\n\tacpi_subsys_runtime_resume\n\trpm_resume\n\ttegra_i2c_xfer\r\n\r\nThe problem arises because during __pm_runtime_resume(), the spinlock\n\u0026amp;dev-\u0026gt;power.lock is acquired before rpm_resume() is called. Later,\nrpm_resume() invokes acpi_subsys_runtime_resume(), which relies on\nmutexes, triggering the error.\r\n\r\nTo address this issue, devices on ACPI are now marked as not IRQ-safe,\nconsidering the dependency of acpi_subsys_runtime_resume() on mutexes.(CVE-2024-45029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: aacraid: Fix double-free on probe failure\r\n\r\naac_probe_one() calls hardware-specific init functions through the\naac_driver_ident::init pointer, all of which eventually call down to\naac_init_adapter().\r\n\r\nIf aac_init_adapter() fails after allocating memory for aac_dev::queues,\nit frees the memory but does not clear that member.\r\n\r\nAfter the hardware-specific init function returns an error,\naac_probe_one() goes down an error path that frees the memory pointed to\nby aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: st: fix probed platform device ref count on probe error path\r\n\r\nThe probe function never performs any paltform device allocation, thus\nerror path \u0026quot;undo_platform_dev_alloc\u0026quot; is entirely bogus.  It drops the\nreference count from the platform device being probed.  If error path is\ntriggered, this will lead to unbalanced device reference counts and\npremature release of device resources, thus possible use-after-free when\nreleasing remaining devm-managed resources.(CVE-2024-46674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethtool: check device is present when getting link settings\r\n\r\nA sysfs reader can race with a device reset or removal, attempting to\nread device state when the device is not actually present. eg:\r\n\r\n     [exception RIP: qed_get_current_link+17]\n  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]\n  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3\n #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4\n #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300\n #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c\n #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b\n #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3\n #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1\n #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f\n #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb\r\n\r\n crash\u0026gt; struct net_device.state ffff9a9d21336000\n    state = 5,\r\n\r\nstate 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).\nThe device is not present, note lack of __LINK_STATE_PRESENT (0b10).\r\n\r\nThis is the same sort of panic as observed in commit 4224cfd7fb65\n(\u0026quot;net-sysfs: add check for netdevice being present to speed_show\u0026quot;).\r\n\r\nThere are many other callers of __ethtool_get_link_ksettings() which\ndon\u0026apos;t have a device presence check.\r\n\r\nMove this check into ethtool to protect all callers.(CVE-2024-46679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npktgen: use cpus_read_lock() in pg_net_init()\r\n\r\nI have seen the WARN_ON(smp_processor_id() != cpu) firing\nin pktgen_thread_worker() during tests.\r\n\r\nWe must use cpus_read_lock()/cpus_read_unlock()\naround the for_each_online_cpu(cpu) loop.\r\n\r\nWhile we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.(CVE-2024-46681)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()\r\n\r\nThis happens when called from SMB2_read() while using rdma\nand reaching the rdma_readwrite_threshold.(CVE-2024-46686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux,smack: don\u0026apos;t bypass permissions check in inode_setsecctx hook\r\n\r\nMarek Gresko reports that the root user on an NFS client is able to\nchange the security labels on files on an NFS filesystem that is\nexported with root squashing enabled.\r\n\r\nThe end of the kerneldoc comment for __vfs_setxattr_noperm() states:\r\n\r\n *  This function requires the caller to lock the inode\u0026apos;s i_mutex before it\n *  is executed. It also assumes that the caller will make the appropriate\n *  permission checks.\r\n\r\nnfsd_setattr() does do permissions checking via fh_verify() and\nnfsd_permission(), but those don\u0026apos;t do all the same permissions checks\nthat are done by security_inode_setxattr() and its related LSM hooks do.\r\n\r\nSince nfsd_setattr() is the only consumer of security_inode_setsecctx(),\nsimplest solution appears to be to replace the call to\n__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This\nfixes the above issue and has the added benefit of causing nfsd to\nrecall conflicting delegations on a file when a client tries to change\nits security label.(CVE-2024-46695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlibfs: fix infinite directory reads for offset dir\r\n\r\nAfter we switch tmpfs dir operations from simple_dir_operations to\nsimple_offset_dir_operations, every rename happened will fill new dentry\nto dest dir\u0026apos;s maple tree(\u0026amp;SHMEM_I(inode)-\u0026gt;dir_offsets-\u0026gt;mt) with a free\nkey starting with octx-\u0026gt;newx_offset, and then set newx_offset equals to\nfree key + 1. This will lead to infinite readdir combine with rename\nhappened at the same time, which fail generic/736 in xfstests(detail show\nas below).\r\n\r\n1. create 5000 files(1 2 3...) under one dir\n2. call readdir(man 3 readdir) once, and get one entry\n3. rename(entry, \u0026quot;TEMPFILE\u0026quot;), then rename(\u0026quot;TEMPFILE\u0026quot;, entry)\n4. loop 2~3, until readdir return nothing or we loop too many\n   times(tmpfs break test with the second condition)\r\n\r\nWe choose the same logic what commit 9b378f6ad48cf (\u0026quot;btrfs: fix infinite\ndirectory reads\u0026quot;) to fix it, record the last_index when we open dir, and\ndo not emit the entry which index \u0026gt;= last_index. The file-\u0026gt;private_data\nnow used in offset dir can use directly to do this, and we also update\nthe last_index when we llseek the dir file.\r\n\r\n[brauner: only update last_index after seek when offset is zero like Jan suggested](CVE-2024-46701)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: SHAMPO, Fix incorrect page release\r\n\r\nUnder the following conditions:\n1) No skb created yet\n2) header_size == 0 (no SHAMPO header)\n3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the\n   last page fragment of a SHAMPO header page)\r\n\r\na new skb is formed with a page that is NOT a SHAMPO header page (it\nis a regular data page). Further down in the same function\n(mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from\nheader_index is released. This is wrong and it leads to SHAMPO header\npages being released more than once.(CVE-2024-46717)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: fix possible NULL pointer dereference\r\n\r\nprofile-\u0026gt;parent-\u0026gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made\nfrom __create_missing_ancestors(..) and \u0026apos;ent-\u0026gt;old\u0026apos; is NULL in\naa_replace_profiles(..).\nIn that case, it must return an error code and the code, -ENOENT represents\nits state that the path of its parent is not existed yet.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x6d/0x80\n ? __die+0x24/0x80\n ? page_fault_oops+0x99/0x1b0\n ? kernelmode_fixup_or_oops+0xb2/0x140\n ? __bad_area_nosemaphore+0x1a5/0x2c0\n ? find_vma+0x34/0x60\n ? bad_area_nosemaphore+0x16/0x30\n ? do_user_addr_fault+0x2a2/0x6b0\n ? exc_page_fault+0x83/0x1b0\n ? asm_exc_page_fault+0x27/0x30\n ? aafs_create.constprop.0+0x7f/0x130\n ? aafs_create.constprop.0+0x51/0x130\n __aafs_profile_mkdir+0x3d6/0x480\n aa_replace_profiles+0x83f/0x1270\n policy_update+0xe3/0x180\n profile_load+0xbc/0x150\n ? rw_verify_area+0x47/0x140\n vfs_write+0x100/0x480\n ? __x64_sys_openat+0x55/0xa0\n ? syscall_exit_to_user_mode+0x86/0x260\n ksys_write+0x73/0x100\n __x64_sys_write+0x19/0x30\n x64_sys_call+0x7e/0x25c0\n do_syscall_64+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7be9f211c574\nCode: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89\nRSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574\nRDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004\nRBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80\nR13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30\n \u0026lt;/TASK\u0026gt;\nModules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas\nCR2: 0000000000000030\n---[ end trace 0000000000000000 ]---\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000\n---truncated---(CVE-2024-46721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix mc_data out-of-bounds read warning\r\n\r\nClear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds write warning\r\n\r\nCheck the ring type value to fix the out-of-bounds\nwrite warning(CVE-2024-46725)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check index for aux_rd_interval before using\r\n\r\naux_rd_interval has size of 7 and should be checked.\r\n\r\nThis fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46728)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Assign linear_pitch_alignment even for VM\r\n\r\n[Description]\nAssign linear_pitch_alignment so we don\u0026apos;t cause a divide by 0\nerror in VM environments(CVE-2024-46732)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix race between direct IO write and fsync when using same fd\r\n\r\nIf we have 2 threads that are using the same file descriptor and one of\nthem is doing direct IO writes while the other is doing fsync, we have a\nrace where we can end up either:\r\n\r\n1) Attempt a fsync without holding the inode\u0026apos;s lock, triggering an\n   assertion failures when assertions are enabled;\r\n\r\n2) Do an invalid memory access from the fsync task because the file private\n   points to memory allocated on stack by the direct IO task and it may be\n   used by the fsync task after the stack was destroyed.\r\n\r\nThe race happens like this:\r\n\r\n1) A user space program opens a file descriptor with O_DIRECT;\r\n\r\n2) The program spawns 2 threads using libpthread for example;\r\n\r\n3) One of the threads uses the file descriptor to do direct IO writes,\n   while the other calls fsync using the same file descriptor.\r\n\r\n4) Call task A the thread doing direct IO writes and task B the thread\n   doing fsyncs;\r\n\r\n5) Task A does a direct IO write, and at btrfs_direct_write() sets the\n   file\u0026apos;s private to an on stack allocated private with the member\n   \u0026apos;fsync_skip_inode_lock\u0026apos; set to true;\r\n\r\n6) Task B enters btrfs_sync_file() and sees that there\u0026apos;s a private\n   structure associated to the file which has \u0026apos;fsync_skip_inode_lock\u0026apos; set\n   to true, so it skips locking the inode\u0026apos;s VFS lock;\r\n\r\n7) Task A completes the direct IO write, and resets the file\u0026apos;s private to\n   NULL since it had no prior private and our private was stack allocated.\n   Then it unlocks the inode\u0026apos;s VFS lock;\r\n\r\n8) Task B enters btrfs_get_ordered_extents_for_logging(), then the\n   assertion that checks the inode\u0026apos;s VFS lock is held fails, since task B\n   never locked it and task A has already unlocked it.\r\n\r\nThe stack trace produced is the following:\r\n\r\n   assertion failed: inode_is_locked(\u0026amp;inode-\u0026gt;vfs_inode), in fs/btrfs/ordered-data.c:983\n   ------------[ cut here ]------------\n   kernel BUG at fs/btrfs/ordered-data.c:983!\n   Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI\n   CPU: 9 PID: 5072 Comm: worker Tainted: G     U     OE      6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8\n   Hardware name: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 07/28/2020\n   RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs]\n   Code: 50 d6 86 c0 e8 (...)\n   RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246\n   RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000\n   RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800\n   RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38\n   R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800\n   R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000\n   FS:  00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000\n   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n   CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0\n   Call Trace:\n    \u0026lt;TASK\u0026gt;\n    ? __die_body.cold+0x14/0x24\n    ? die+0x2e/0x50\n    ? do_trap+0xca/0x110\n    ? do_error_trap+0x6a/0x90\n    ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    ? exc_invalid_op+0x50/0x70\n    ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    ? asm_exc_invalid_op+0x1a/0x20\n    ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    btrfs_sync_file+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n    ? __seccomp_filter+0x31d/0x4f0\n    __x64_sys_fdatasync+0x4f/0x90\n    do_syscall_64+0x82/0x160\n    ? do_futex+0xcb/0x190\n    ? __x64_sys_futex+0x10e/0x1d0\n    ? switch_fpu_return+0x4f/0xd0\n    ? syscall_exit_to_user_mode+0x72/0x220\n    ? do_syscall_64+0x8e/0x160\n    ? syscall_exit_to_user_mod\n---truncated---(CVE-2024-46734)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix double put of @cfile in smb2_rename_path()\r\n\r\nIf smb2_set_path_attr() is called with a valid @cfile and returned\n-EINVAL, we need to call cifs_get_writable_path() again as the\nreference of @cfile was already dropped by previous smb2_compound_op()\ncall.(CVE-2024-46736)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet-tcp: fix kernel crash if commands allocation fails\r\n\r\nIf the commands allocation fails in nvmet_tcp_alloc_cmds()\nthe kernel crashes in nvmet_tcp_release_queue_work() because of\na NULL pointer dereference.\r\n\r\n  nvmet: failed to install queue 0 cntlid 1 ret 6\n  Unable to handle kernel NULL pointer dereference at\n         virtual address 0000000000000008\r\n\r\nFix the bug by setting queue-\u0026gt;nr_cmds to zero in case\nnvmet_tcp_alloc_cmd() fails.(CVE-2024-46737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nVMCI: Fix use-after-free when removing resource in vmci_resource_remove()\r\n\r\nWhen removing a resource from vmci_resource_table in\nvmci_resource_remove(), the search is performed using the resource\nhandle by comparing context and resource fields.\r\n\r\nIt is possible though to create two resources with different types\nbut same handle (same context and resource fields).\r\n\r\nWhen trying to remove one of the resources, vmci_resource_remove()\nmay not remove the intended one, but the object will still be freed\nas in the case of the datagram type in vmci_datagram_destroy_handle().\nvmci_resource_table will still hold a pointer to this freed resource\nleading to a use-after-free vulnerability.\r\n\r\nBUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\nBUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\nRead of size 4 at addr ffff88801c16d800 by task syz-executor197/1592\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106\n print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239\n __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425\n kasan_report+0x38/0x51 mm/kasan/report.c:442\n vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\n vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\n vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182\n ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444\n kref_put include/linux/kref.h:65 [inline]\n vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]\n vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195\n vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143\n __fput+0x261/0xa34 fs/file_table.c:282\n task_work_run+0xf0/0x194 kernel/task_work.c:164\n tracehook_notify_resume include/linux/tracehook.h:189 [inline]\n exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187\n exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220\n __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]\n syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313\n do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\r\n\r\nThis change ensures the type is also checked when removing\nthe resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind\r\n\r\nFor primary VM Bus channels, primary_channel pointer is always NULL. This\npointer is valid only for the secondary channels. Also, rescind callback\nis meant for primary channels only.\r\n\r\nFix NULL pointer dereference by retrieving the device_obj from the parent\nfor the primary channel.(CVE-2024-46739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix UAF caused by offsets overwrite\r\n\r\nBinder objects are processed and copied individually into the target\nbuffer during transactions. Any raw data in-between these objects is\ncopied as well. However, this raw data copy lacks an out-of-bounds\ncheck. If the raw data exceeds the data section size then the copy\noverwrites the offsets section. This eventually triggers an error that\nattempts to unwind the processed objects. However, at this point the\noffsets used to index these objects are now corrupted.\r\n\r\nUnwinding with corrupted offsets can result in decrements of arbitrary\nnodes and lead to their premature release. Other users of such nodes are\nleft with a dangling pointer triggering a use-after-free. This issue is\nmade evident by the following KASAN report (trimmed):\r\n\r\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c\n  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743\r\n\r\n  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   _raw_spin_lock+0xe4/0x19c\n   binder_free_buf+0x128/0x434\n   binder_thread_write+0x8a4/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Allocated by task 743:\n   __kmalloc_cache_noprof+0x110/0x270\n   binder_new_node+0x50/0x700\n   binder_transaction+0x413c/0x6da8\n   binder_thread_write+0x978/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Freed by task 745:\n   kfree+0xbc/0x208\n   binder_thread_read+0x1c5c/0x37d4\n   binder_ioctl+0x16d8/0x258c\n  [...]\n  ==================================================================\r\n\r\nTo avoid this issue, let\u0026apos;s check that the raw data copy is within the\nboundaries of the data section.(CVE-2024-46740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: Add missing bridge lock to pci_bus_lock()\r\n\r\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\r\n\r\n  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __warn+0x8c/0x190\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   ? report_bug+0x1f8/0x200\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   pci_reset_bus+0x1d8/0x270\n   vmd_probe+0x778/0xa10\n   pci_device_probe+0x95/0x120\r\n\r\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\r\n\r\nFor the same motivation as adding:\r\n\r\n  bridge = pci_upstream_bridge(dev);\n  if (bridge)\n    pci_dev_lock(bridge);\r\n\r\nto pci_reset_function() for the \u0026quot;bus\u0026quot; and \u0026quot;cxl_bus\u0026quot; reset cases, add\npci_dev_lock() for @bus-\u0026gt;self to pci_bus_lock().\r\n\r\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com](CVE-2024-46750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle errors from btrfs_dec_ref() properly\r\n\r\nIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is\nincorrect, we have proper error handling here, return the error.(CVE-2024-46753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()\r\n\r\nmwifiex_get_priv_by_id() returns the priv pointer corresponding to\nthe bss_num and bss_type, but without checking if the priv is actually\ncurrently in use.\nUnused priv pointers do not have a wiphy attached to them which can\nlead to NULL pointer dereferences further down the callstack.  Fix\nthis by returning only used priv pointers which have priv-\u0026gt;bss_mode\nset to something else than NL80211_IFTYPE_UNSPECIFIED.\r\n\r\nSaid NULL pointer dereference happened when an Accesspoint was started\nwith wpa_supplicant -i mlan0 with this config:\r\n\r\nnetwork={\n        ssid=\u0026quot;somessid\u0026quot;\n        mode=2\n        frequency=2412\n        key_mgmt=WPA-PSK WPA-PSK-SHA256\n        proto=RSN\n        group=CCMP\n        pairwise=CCMP\n        psk=\u0026quot;12345678\u0026quot;\n}\r\n\r\nWhen waiting for the AP to be established, interrupting wpa_supplicant\nwith \u0026lt;ctrl-c\u0026gt; and starting it again this happens:\r\n\r\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140\n| Mem abort info:\n|   ESR = 0x0000000096000004\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x04: level 0 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000\n| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000\n| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio\n+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs\n+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6\n| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18\n| Hardware name: somemachine (DT)\n| Workqueue: events sdio_irq_work\n| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]\n| sp : ffff8000818b3a70\n| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004\n| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9\n| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000\n| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000\n| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517\n| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1\n| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157\n| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124\n| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000\n| Call trace:\n|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]\n|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]\n|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]\n|  mwifiex_process_event+0x110/0x238 [mwifiex]\n|  mwifiex_main_process+0x428/0xa44 [mwifiex]\n|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]\n|  process_sdio_pending_irqs+0x64/0x1b8\n|  sdio_irq_work+0x4c/0x7c\n|  process_one_work+0x148/0x2a0\n|  worker_thread+0x2fc/0x40c\n|  kthread+0x110/0x114\n|  ret_from_fork+0x10/0x20\n| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)\n| ---[ end trace 0000000000000000 ]---(CVE-2024-46755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (w83627ehf) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (lm95234) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46758)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: rtw88: usb: schedule rx work after everything is set up\r\n\r\nRight now it\u0026apos;s possible to hit NULL pointer dereference in\nrtw_rx_fill_rx_status on hw object and/or its fields because\ninitialization routine can start getting USB replies before\nrtw_dev is fully setup.\r\n\r\nThe stack trace looks like this:\r\n\r\nrtw_rx_fill_rx_status\nrtw8821c_query_rx_desc\nrtw_usb_rx_handler\n...\nqueue_work\nrtw_usb_read_port_complete\n...\nusb_submit_urb\nrtw_usb_rx_resubmit\nrtw_usb_init_rx\nrtw_usb_probe\r\n\r\nSo while we do the async stuff rtw_usb_probe continues and calls\nrtw_register_hw, which does all kinds of initialization (e.g.\nvia ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.\r\n\r\nFix this by moving the first usb_submit_urb after everything\nis set up.\r\n\r\nFor me, this bug manifested as:\n[    8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped\n[    8.910904] rtw_8821cu 1-1:1.2: hw-\u0026gt;conf.chandef.chan NULL in rtw_rx_fill_rx_status\nbecause I\u0026apos;m using Larry\u0026apos;s backport of rtw88 driver with the NULL\nchecks in rtw_rx_fill_rx_status.(CVE-2024-46760)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npci/hotplug/pnv_php: Fix hotplug driver crash on Powernv\r\n\r\nThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel\ncrash when we try to hot-unplug/disable the PCIe switch/bridge from\nthe PHB.\r\n\r\nThe crash occurs because although the MSI data structure has been\nreleased during disable/hot-unplug path and it has been assigned\nwith NULL, still during unregistration the code was again trying to\nexplicitly disable the MSI which causes the NULL pointer dereference and\nkernel crash.\r\n\r\nThe patch fixes the check during unregistration path to prevent invoking\npci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: phy: Fix missing of_node_put() for leds\r\n\r\nThe call of of_get_child_by_name() will cause refcount incremented\nfor leds, if it succeeds, it should call of_node_put() to decrease\nit, fix it.(CVE-2024-46767)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (hp-wmi-sensors) Check if WMI event data exists\r\n\r\nThe BIOS can choose to return no event data in response to a\nWMI event, so the ACPI object passed to the WMI notify handler\ncan be NULL.\r\n\r\nCheck for such a situation and ignore the event in such a case.(CVE-2024-46768)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: bcm: Remove proc entry when dev is unregistered.\r\n\r\nsyzkaller reported a warning in bcm_connect() below. [0]\r\n\r\nThe repro calls connect() to vxcan1, removes vxcan1, and calls\nconnect() with ifindex == 0.\r\n\r\nCalling connect() for a BCM socket allocates a proc entry.\nThen, bcm_sk(sk)-\u0026gt;bound is set to 1 to prevent further connect().\r\n\r\nHowever, removing the bound device resets bcm_sk(sk)-\u0026gt;bound to 0\nin bcm_notify().\r\n\r\nThe 2nd connect() tries to allocate a proc entry with the same\nname and sets NULL to bcm_sk(sk)-\u0026gt;bcm_proc_read, leaking the\noriginal proc entry.\r\n\r\nSince the proc entry is available only for connect()ed sockets,\nlet\u0026apos;s clean up the entry when the bound netdev is unregistered.\r\n\r\n[0]:\nproc_dir_entry \u0026apos;can-bcm/2456\u0026apos; already registered\nWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375\nModules linked in:\nCPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375\nCode: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 \u0026lt;0f\u0026gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48\nRSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246\nRAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002\nRBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0\nR10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec\nFS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220\n bcm_connect+0x472/0x840 net/can/bcm.c:1673\n __sys_connect_file net/socket.c:2049 [inline]\n __sys_connect+0x5d2/0x690 net/socket.c:2066\n __do_sys_connect net/socket.c:2076 [inline]\n __se_sys_connect net/socket.c:2073 [inline]\n __x64_sys_connect+0x8f/0x100 net/socket.c:2073\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fbd708b0e5d\nCode: 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 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d\nRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040\nR10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098\nR13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000\n \u0026lt;/TASK\u0026gt;\nremove_proc_entry: removing non-empty directory \u0026apos;net/can-bcm\u0026apos;, leaking at least \u0026apos;2456\u0026apos;(CVE-2024-46771)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check denominator crb_pipes before used\r\n\r\n[WHAT \u0026amp; HOW]\nA denominator cannot be 0, and is checked before used.\r\n\r\nThis fixes 2 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-46772)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check denominator pbn_div before used\r\n\r\n[WHAT \u0026amp; HOW]\nA denominator cannot be 0, and is checked before used.\r\n\r\nThis fixes 1 DIVIDE_BY_ZERO issue reported by Coverity.(CVE-2024-46773)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Run DC_LOG_DC after checking link-\u0026gt;link_enc\r\n\r\n[WHAT]\nThe DC_LOG_DC should be run after link-\u0026gt;link_enc is checked, not before.\r\n\r\nThis fixes 1 REVERSE_INULL issue reported by Coverity.(CVE-2024-46776)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid excessive partition lengths\r\n\r\nAvoid mounting filesystems where the partition would overflow the\n32-bits used for block number. Also refuse to mount filesystems where\nthe partition length is so large we cannot safely index bits in a\nblock bitmap.(CVE-2024-46777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: protect references to superblock parameters exposed in sysfs\r\n\r\nThe superblock buffers of nilfs2 can not only be overwritten at runtime\nfor modifications/repairs, but they are also regularly swapped, replaced\nduring resizing, and even abandoned when degrading to one side due to\nbacking device issues.  So, accessing them requires mutual exclusion using\nthe reader/writer semaphore \u0026quot;nilfs-\u0026gt;ns_sem\u0026quot;.\r\n\r\nSome sysfs attribute show methods read this superblock buffer without the\nnecessary mutual exclusion, which can cause problems with pointer\ndereferencing and memory access, so fix it.(CVE-2024-46780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix missing cleanup on rollforward recovery error\r\n\r\nIn an error injection test of a routine for mount-time recovery, KASAN\nfound a use-after-free bug.\r\n\r\nIt turned out that if data recovery was performed using partial logs\ncreated by dsync writes, but an error occurred before starting the log\nwriter to create a recovered checkpoint, the inodes whose data had been\nrecovered were left in the ns_dirty_files list of the nilfs object and\nwere not freed.\r\n\r\nFix this issue by cleaning up inodes that have read the recovery data if\nthe recovery routine fails midway before the log writer starts.(CVE-2024-46781)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: mana: Fix error handling in mana_create_txq/rxq\u0026apos;s NAPI cleanup\r\n\r\nCurrently napi_disable() gets called during rxq and txq cleanup,\neven before napi is enabled and hrtimer is initialized. It causes\nkernel panic.\r\n\r\n? page_fault_oops+0x136/0x2b0\n  ? page_counter_cancel+0x2e/0x80\n  ? do_user_addr_fault+0x2f2/0x640\n  ? refill_obj_stock+0xc4/0x110\n  ? exc_page_fault+0x71/0x160\n  ? asm_exc_page_fault+0x27/0x30\n  ? __mmdrop+0x10/0x180\n  ? __mmdrop+0xec/0x180\n  ? hrtimer_active+0xd/0x50\n  hrtimer_try_to_cancel+0x2c/0xf0\n  hrtimer_cancel+0x15/0x30\n  napi_disable+0x65/0x90\n  mana_destroy_rxq+0x4c/0x2f0\n  mana_create_rxq.isra.0+0x56c/0x6d0\n  ? mana_uncfg_vport+0x50/0x50\n  mana_alloc_queues+0x21b/0x320\n  ? skb_dequeue+0x5f/0x80(CVE-2024-46784)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuserfaultfd: fix checks for huge PMDs\r\n\r\nPatch series \u0026quot;userfaultfd: fix races around pmd_trans_huge() check\u0026quot;, v2.\r\n\r\nThe pmd_trans_huge() code in mfill_atomic() is wrong in three different\nways depending on kernel version:\r\n\r\n1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit\n   the right two race windows) - I\u0026apos;ve tested this in a kernel build with\n   some extra mdelay() calls. See the commit message for a description\n   of the race scenario.\n   On older kernels (before 6.5), I think the same bug can even\n   theoretically lead to accessing transhuge page contents as a page table\n   if you hit the right 5 narrow race windows (I haven\u0026apos;t tested this case).\n2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for\n   detecting PMDs that don\u0026apos;t point to page tables.\n   On older kernels (before 6.5), you\u0026apos;d just have to win a single fairly\n   wide race to hit this.\n   I\u0026apos;ve tested this on 6.1 stable by racing migration (with a mdelay()\n   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86\n   VM, that causes a kernel oops in ptlock_ptr().\n3. On newer kernels (\u0026gt;=6.5), for shmem mappings, khugepaged is allowed\n   to yank page tables out from under us (though I haven\u0026apos;t tested that),\n   so I think the BUG_ON() checks in mfill_atomic() are just wrong.\r\n\r\nI decided to write two separate fixes for these (one fix for bugs 1+2, one\nfix for bug 3), so that the first fix can be backported to kernels\naffected by bugs 1+2.\r\n\r\n\nThis patch (of 2):\r\n\r\nThis fixes two issues.\r\n\r\nI discovered that the following race can occur:\r\n\r\n  mfill_atomic                other thread\n  ============                ============\n                              \u0026lt;zap PMD\u0026gt;\n  pmdp_get_lockless() [reads none pmd]\n  \u0026lt;bail if trans_huge\u0026gt;\n  \u0026lt;if none:\u0026gt;\n                              \u0026lt;pagefault creates transhuge zeropage\u0026gt;\n    __pte_alloc [no-op]\n                              \u0026lt;zap PMD\u0026gt;\n  \u0026lt;bail if pmd_trans_huge(*dst_pmd)\u0026gt;\n  BUG_ON(pmd_none(*dst_pmd))\r\n\r\nI have experimentally verified this in a kernel with extra mdelay() calls;\nthe BUG_ON(pmd_none(*dst_pmd)) triggers.\r\n\r\nOn kernels newer than commit 0d940a9b270b (\u0026quot;mm/pgtable: allow\npte_offset_map[_lock]() to fail\u0026quot;), this can\u0026apos;t lead to anything worse than\na BUG_ON(), since the page table access helpers are actually designed to\ndeal with page tables concurrently disappearing; but on older kernels\n(\u0026lt;=6.4), I think we could probably theoretically race past the two\nBUG_ON() checks and end up treating a hugepage as a page table.\r\n\r\nThe second issue is that, as Qi Zheng pointed out, there are other types\nof huge PMDs that pmd_trans_huge() can\u0026apos;t catch: devmap PMDs and swap PMDs\n(in particular, migration PMDs).\r\n\r\nOn \u0026lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a\nPMD that contains a migration entry (which just requires winning a single,\nfairly wide race), it will pass the PMD to pte_offset_map_lock(), which\nassumes that the PMD points to a page table.\r\n\r\nBreakage follows: First, the kernel tries to take the PTE lock (which will\ncrash or maybe worse if there is no \u0026quot;struct page\u0026quot; for the address bits in\nthe migration entry PMD - I think at least on X86 there usually is no\ncorresponding \u0026quot;struct page\u0026quot; thanks to the PTE inversion mitigation, amd64\nlooks different).\r\n\r\nIf that didn\u0026apos;t crash, the kernel would next try to write a PTE into what\nit wrongly thinks is a page table.\r\n\r\nAs part of fixing these issues, get rid of the check for pmd_trans_huge()\nbefore __pte_alloc() - that\u0026apos;s redundant, we\u0026apos;re going to have to check for\nthat after the __pte_alloc() anyway.\r\n\r\nBackport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.(CVE-2024-46787)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing/osnoise: Use a cpumask to know what threads are kthreads\r\n\r\nThe start_kthread() and stop_thread() code was not always called with the\ninterface_lock held. This means that the kthread variable could be\nunexpectedly changed causing the kthread_stop() to be called on it when it\nshould not have been, leading to:\r\n\r\n while true; do\n   rtla timerlat top -u -q \u0026amp; PID=$!;\n   sleep 5;\n   kill -INT $PID;\n   sleep 0.001;\n   kill -TERM $PID;\n   wait $PID;\n  done\r\n\r\nCausing the following OOPS:\r\n\r\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:hrtimer_active+0x58/0x300\n Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 \u0026lt;0f\u0026gt; b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f\n RSP: 0018:ffff88811d97f940 EFLAGS: 00010202\n RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b\n RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28\n RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60\n R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d\n R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28\n FS:  0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? die_addr+0x40/0xa0\n  ? exc_general_protection+0x154/0x230\n  ? asm_exc_general_protection+0x26/0x30\n  ? hrtimer_active+0x58/0x300\n  ? __pfx_mutex_lock+0x10/0x10\n  ? __pfx_locks_remove_file+0x10/0x10\n  hrtimer_cancel+0x15/0x40\n  timerlat_fd_release+0x8e/0x1f0\n  ? security_file_release+0x43/0x80\n  __fput+0x372/0xb10\n  task_work_run+0x11e/0x1f0\n  ? _raw_spin_lock+0x85/0xe0\n  ? __pfx_task_work_run+0x10/0x10\n  ? poison_slab_object+0x109/0x170\n  ? do_exit+0x7a0/0x24b0\n  do_exit+0x7bd/0x24b0\n  ? __pfx_migrate_enable+0x10/0x10\n  ? __pfx_do_exit+0x10/0x10\n  ? __pfx_read_tsc+0x10/0x10\n  ? ktime_get+0x64/0x140\n  ? _raw_spin_lock_irq+0x86/0xe0\n  do_group_exit+0xb0/0x220\n  get_signal+0x17ba/0x1b50\n  ? vfs_read+0x179/0xa40\n  ? timerlat_fd_read+0x30b/0x9d0\n  ? __pfx_get_signal+0x10/0x10\n  ? __pfx_timerlat_fd_read+0x10/0x10\n  arch_do_signal_or_restart+0x8c/0x570\n  ? __pfx_arch_do_signal_or_restart+0x10/0x10\n  ? vfs_read+0x179/0xa40\n  ? ksys_read+0xfe/0x1d0\n  ? __pfx_ksys_read+0x10/0x10\n  syscall_exit_to_user_mode+0xbc/0x130\n  do_syscall_64+0x74/0x110\n  ? __pfx___rseq_handle_notify_resume+0x10/0x10\n  ? __pfx_ksys_read+0x10/0x10\n  ? fpregs_restore_userregs+0xdb/0x1e0\n  ? fpregs_restore_userregs+0xdb/0x1e0\n  ? syscall_exit_to_user_mode+0x116/0x130\n  ? do_syscall_64+0x74/0x110\n  ? do_syscall_64+0x74/0x110\n  ? do_syscall_64+0x74/0x110\n  entry_SYSCALL_64_after_hwframe+0x71/0x79\n RIP: 0033:0x7ff0070eca9c\n Code: Unable to access opcode bytes at 0x7ff0070eca72.\n RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c\n RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003\n RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0\n R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003\n R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008\n  \u0026lt;/TASK\u0026gt;\n Modules linked in: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core\n ---[ end trace 0000000000000000 ]---\r\n\r\nThis is because it would mistakenly call kthread_stop() on a user space\nthread making it \u0026quot;exit\u0026quot; before it actually exits.\r\n\r\nSince kthread\n---truncated---(CVE-2024-46788)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\r\n\r\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\r\n\r\nCPU0                           CPU1\n----                           ----\nmcp251x_open()\n mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  request_threaded_irq()\n                               \u0026lt;interrupt\u0026gt;\n                               mcp251x_can_ist()\n                                mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  mcp251x_hw_wake()\n   disable_irq() \u0026lt;-- deadlock\r\n\r\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn\u0026apos;t matter if it\u0026apos;s still\nrunning.(CVE-2024-46791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix double put of @cfile in smb2_set_path_size()\r\n\r\nIf smb2_compound_op() is called with a valid @cfile and returned\n-EINVAL, we need to call cifs_get_writable_path() before retrying it\nas the reference of @cfile was already dropped by previous call.\r\n\r\nThis fixes the following KASAN splat when running fstests generic/013\nagainst Windows Server 2022:\r\n\r\n  CIFS: Attempting to mount //w22-fs0/scratch\n  run fstests generic/013 at 2024-09-02 19:48:59\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in detach_if_pending+0xab/0x200\n  Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176\r\n\r\n  CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40\n  04/01/2014\n  Workqueue: cifsoplockd cifs_oplock_break [cifs]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x5d/0x80\n   ? detach_if_pending+0xab/0x200\n   print_report+0x156/0x4d9\n   ? detach_if_pending+0xab/0x200\n   ? __virt_addr_valid+0x145/0x300\n   ? __phys_addr+0x46/0x90\n   ? detach_if_pending+0xab/0x200\n   kasan_report+0xda/0x110\n   ? detach_if_pending+0xab/0x200\n   detach_if_pending+0xab/0x200\n   timer_delete+0x96/0xe0\n   ? __pfx_timer_delete+0x10/0x10\n   ? rcu_is_watching+0x20/0x50\n   try_to_grab_pending+0x46/0x3b0\n   __cancel_work+0x89/0x1b0\n   ? __pfx___cancel_work+0x10/0x10\n   ? kasan_save_track+0x14/0x30\n   cifs_close_deferred_file+0x110/0x2c0 [cifs]\n   ? __pfx_cifs_close_deferred_file+0x10/0x10 [cifs]\n   ? __pfx_down_read+0x10/0x10\n   cifs_oplock_break+0x4c1/0xa50 [cifs]\n   ? __pfx_cifs_oplock_break+0x10/0x10 [cifs]\n   ? lock_is_held_type+0x85/0xf0\n   ? mark_held_locks+0x1a/0x90\n   process_one_work+0x4c6/0x9f0\n   ? find_held_lock+0x8a/0xa0\n   ? __pfx_process_one_work+0x10/0x10\n   ? lock_acquired+0x220/0x550\n   ? __list_add_valid_or_report+0x37/0x100\n   worker_thread+0x2e4/0x570\n   ? __kthread_parkme+0xd1/0xf0\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x17f/0x1c0\n   ? kthread+0xda/0x1c0\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x31/0x60\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   \u0026lt;/TASK\u0026gt;\r\n\r\n  Allocated by task 1118:\n   kasan_save_stack+0x30/0x50\n   kasan_save_track+0x14/0x30\n   __kasan_kmalloc+0xaa/0xb0\n   cifs_new_fileinfo+0xc8/0x9d0 [cifs]\n   cifs_atomic_open+0x467/0x770 [cifs]\n   lookup_open.isra.0+0x665/0x8b0\n   path_openat+0x4c3/0x1380\n   do_filp_open+0x167/0x270\n   do_sys_openat2+0x129/0x160\n   __x64_sys_creat+0xad/0xe0\n   do_syscall_64+0xbb/0x1d0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\n  Freed by task 83:\n   kasan_save_stack+0x30/0x50\n   kasan_save_track+0x14/0x30\n   kasan_save_free_info+0x3b/0x70\n   poison_slab_object+0xe9/0x160\n   __kasan_slab_free+0x32/0x50\n   kfree+0xf2/0x300\n   process_one_work+0x4c6/0x9f0\n   worker_thread+0x2e4/0x570\n   kthread+0x17f/0x1c0\n   ret_from_fork+0x31/0x60\n   ret_from_fork_asm+0x1a/0x30\r\n\r\n  Last potentially related work creation:\n   kasan_save_stack+0x30/0x50\n   __kasan_record_aux_stack+0xad/0xc0\n   insert_work+0x29/0xe0\n   __queue_work+0x5ea/0x760\n   queue_work_on+0x6d/0x90\n   _cifsFileInfo_put+0x3f6/0x770 [cifs]\n   smb2_compound_op+0x911/0x3940 [cifs]\n   smb2_set_path_size+0x228/0x270 [cifs]\n   cifs_set_file_size+0x197/0x460 [cifs]\n   cifs_setattr+0xd9c/0x14b0 [cifs]\n   notify_change+0x4e3/0x740\n   do_truncate+0xfa/0x180\n   vfs_truncate+0x195/0x200\n   __x64_sys_truncate+0x109/0x150\n   do_syscall_64+0xbb/0x1d0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-46796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/qspinlock: Fix deadlock in MCS queue\r\n\r\nIf an interrupt occurs in queued_spin_lock_slowpath() after we increment\nqnodesp-\u0026gt;count and before node-\u0026gt;lock is initialized, another CPU might\nsee stale lock values in get_tail_qnode(). If the stale lock value happens\nto match the lock on that CPU, then we write to the \u0026quot;next\u0026quot; pointer of\nthe wrong qnode. This causes a deadlock as the former CPU, once it becomes\nthe head of the MCS queue, will spin indefinitely until it\u0026apos;s \u0026quot;next\u0026quot; pointer\nis set by its successor in the queue.\r\n\r\nRunning stress-ng on a 16 core (16EC/16VP) shared LPAR, results in\noccasional lockups similar to the following:\r\n\r\n   $ stress-ng --all 128 --vm-bytes 80% --aggressive \\\n               --maximize --oomable --verify  --syslog \\\n               --metrics  --times  --timeout 5m\r\n\r\n   watchdog: CPU 15 Hard LOCKUP\n   ......\n   NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490\n   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90\n   Call Trace:\n    0xc000002cfffa3bf0 (unreliable)\n    _raw_spin_lock+0x6c/0x90\n    raw_spin_rq_lock_nested.part.135+0x4c/0xd0\n    sched_ttwu_pending+0x60/0x1f0\n    __flush_smp_call_function_queue+0x1dc/0x670\n    smp_ipi_demux_relaxed+0xa4/0x100\n    xive_muxed_ipi_action+0x20/0x40\n    __handle_irq_event_percpu+0x80/0x240\n    handle_irq_event_percpu+0x2c/0x80\n    handle_percpu_irq+0x84/0xd0\n    generic_handle_irq+0x54/0x80\n    __do_irq+0xac/0x210\n    __do_IRQ+0x74/0xd0\n    0x0\n    do_IRQ+0x8c/0x170\n    hardware_interrupt_common_virt+0x29c/0x2a0\n   --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490\n   ......\n   NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490\n   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90\n   --- interrupt: 500\n    0xc0000029c1a41d00 (unreliable)\n    _raw_spin_lock+0x6c/0x90\n    futex_wake+0x100/0x260\n    do_futex+0x21c/0x2a0\n    sys_futex+0x98/0x270\n    system_call_exception+0x14c/0x2f0\n    system_call_vectored_common+0x15c/0x2ec\r\n\r\nThe following code flow illustrates how the deadlock occurs.\nFor the sake of brevity, assume that both locks (A and B) are\ncontended and we call the queued_spin_lock_slowpath() function.\r\n\r\n        CPU0                                   CPU1\n        ----                                   ----\n  spin_lock_irqsave(A)                          |\n  spin_unlock_irqrestore(A)                     |\n    spin_lock(B)                                |\n         |                                      |\n         ▼                                      |\n   id = qnodesp-\u0026gt;count++;                       |\n  (Note that nodes[0].lock == A)                |\n         |                                      |\n         ▼                                      |\n      Interrupt                                 |\n  (happens before \u0026quot;nodes[0].lock = B\u0026quot;)          |\n         |                                      |\n         ▼                                      |\n  spin_lock_irqsave(A)                          |\n         |                                      |\n         ▼                                      |\n   id = qnodesp-\u0026gt;count++                        |\n   nodes[1].lock = A                            |\n         |                                      |\n         ▼                                      |\n  Tail of MCS queue                             |\n         |                             spin_lock_irqsave(A)\n         ▼                                      |\n  Head of MCS queue                             ▼\n         |                             CPU0 is previous tail\n         ▼                                      |\n   Spin indefinitely                            ▼\n  (until \u0026quot;nodes[1].next != NULL\u0026quot;)      prev = get_tail_qnode(A, CPU0)\n                                                |\n                                                ▼\n                                       prev == \u0026amp;qnodes[CPU0].nodes[0]\n                                     (as qnodes\n---truncated---(CVE-2024-46797)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: dapm: Fix UAF for snd_soc_pcm_runtime object\r\n\r\nWhen using kernel with the following extra config,\r\n\r\n  - CONFIG_KASAN=y\n  - CONFIG_KASAN_GENERIC=y\n  - CONFIG_KASAN_INLINE=y\n  - CONFIG_KASAN_VMALLOC=y\n  - CONFIG_FRAME_WARN=4096\r\n\r\nkernel detects that snd_pcm_suspend_all() access a freed\n\u0026apos;snd_soc_pcm_runtime\u0026apos; object when the system is suspended, which\nleads to a use-after-free bug:\r\n\r\n[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270\n[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330\r\n\r\n[   52.047785] Call trace:\n[   52.047787]  dump_backtrace+0x0/0x3c0\n[   52.047794]  show_stack+0x34/0x50\n[   52.047797]  dump_stack_lvl+0x68/0x8c\n[   52.047802]  print_address_description.constprop.0+0x74/0x2c0\n[   52.047809]  kasan_report+0x210/0x230\n[   52.047815]  __asan_report_load1_noabort+0x3c/0x50\n[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270\n[   52.047824]  snd_soc_suspend+0x19c/0x4e0\r\n\r\nThe snd_pcm_sync_stop() has a NULL check on \u0026apos;substream-\u0026gt;runtime\u0026apos; before\nmaking any access. So we need to always set \u0026apos;substream-\u0026gt;runtime\u0026apos; to NULL\neverytime we kfree() it.(CVE-2024-46798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add array index check for hdcp ddc access\r\n\r\n[Why]\nCoverity reports OVERRUN warning. Do not check if array\nindex valid.\r\n\r\n[How]\nCheck msg_id valid and valid array index.(CVE-2024-46804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix the warning division or modulo by zero\r\n\r\nChecks the partition mode and returns an error for an invalid mode.(CVE-2024-46806)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box\r\n\r\n[Why]\nCoverity reports OVERRUN warning. soc.num_states could\nbe 40. But array range of bw_params-\u0026gt;clk_table.entries is 8.\r\n\r\n[How]\nAssert if soc.num_states greater than 8.(CVE-2024-46811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration\r\n\r\n[Why]\nCoverity reports Memory - illegal accesses.\r\n\r\n[How]\nSkip inactive planes.(CVE-2024-46812)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check msg_id before processing transcation\r\n\r\n[WHY \u0026amp; HOW]\nHDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid\narray index, and it needs checking before used.\r\n\r\nThis fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-46814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links\r\n\r\n[Why]\nCoverity report OVERRUN warning. There are\nonly max_links elements within dc-\u0026gt;links. link\ncount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.\r\n\r\n[How]\nMake sure link count less than max_links.(CVE-2024-46816)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check gpio_id before used as array index\r\n\r\n[WHY \u0026amp; HOW]\nGPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore\nshould be checked in advance.\r\n\r\nThis fixes 5 OVERRUN issues reported by Coverity.(CVE-2024-46818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath12k: fix firmware crash due to invalid peer nss\r\n\r\nCurrently, if the access point receives an association\nrequest containing an Extended HE Capabilities Information\nElement with an invalid MCS-NSS, it triggers a firmware\ncrash.\r\n\r\nThis issue arises when EHT-PHY capabilities shows support\nfor a bandwidth and MCS-NSS set for that particular\nbandwidth is filled by zeros and due to this, driver obtains\npeer_nss as 0 and sending this value to firmware causes\ncrash.\r\n\r\nAddress this issue by implementing a validation step for\nthe peer_nss value before passing it to the firmware. If\nthe value is greater than zero, proceed with forwarding\nit to the firmware. However, if the value is invalid,\nreject the association request to prevent potential\nfirmware crashes.\r\n\r\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1(CVE-2024-46827)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtmutex: Drop rt_mutex::wait_lock before scheduling\r\n\r\nrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the\ngood case it returns with the lock held and in the deadlock case it emits a\nwarning and goes into an endless scheduling loop with the lock held, which\ntriggers the \u0026apos;scheduling in atomic\u0026apos; warning.\r\n\r\nUnlock rt_mutex::wait_lock in the dead lock case before issuing the warning\nand dropping into the schedule for ever loop.\r\n\r\n[ tglx: Moved unlock before the WARN(), removed the pointless comment,\n  \tmassaged changelog, added Fixes tag ](CVE-2024-46829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()\r\n\r\nWe handle errors here properly, ENOMEM isn\u0026apos;t fatal, return the error.(CVE-2024-46841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info\r\n\r\nThe MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the\nroutine unconditionally frees submitted mailbox commands regardless of\nreturn status.  The issue is that for MBX_TIMEOUT cases, when firmware\nreturns SFP information at a later time, that same mailbox memory region\nreferences previously freed memory in its cmpl routine.\r\n\r\nFix by adding checks for the MBX_TIMEOUT return code.  During mailbox\nresource cleanup, check the mbox flag to make sure that the wait did not\ntimeout.  If the MBOX_WAKE flag is not set, then do not free the resources\nbecause it will be freed when firmware completes the mailbox at a later\ntime in its cmpl routine.\r\n\r\nAlso, increase the timeout from 30 to 60 seconds to accommodate boot\nscripts requiring longer timeouts.(CVE-2024-46842)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: ufs: core: Remove SCSI host only if added\r\n\r\nIf host tries to remove ufshcd driver from a UFS device it would cause a\nkernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before\nadding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host\nhas been defered after MCQ configuration introduced by commit 0cab4023ec7b\n(\u0026quot;scsi: ufs: core: Defer adding host to SCSI if MCQ is supported\u0026quot;).\r\n\r\nTo guarantee that SCSI host is removed only if it has been added, set the\nscsi_host_added flag to true after adding a SCSI host and check whether it\nis set or not before removing it.(CVE-2024-46843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: line: always fill *error_out in setup_one_line()\r\n\r\nThe pointer isn\u0026apos;t initialized by callers, but I have\nencountered cases where it\u0026apos;s still printed; initialize\nit in all possible cases in setup_one_line().(CVE-2024-46844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing/timerlat: Only clear timer if a kthread exists\r\n\r\nThe timerlat tracer can use user space threads to check for osnoise and\ntimer latency. If the program using this is killed via a SIGTERM, the\nthreads are shutdown one at a time and another tracing instance can start\nup resetting the threads before they are fully closed. That causes the\nhrtimer assigned to the kthread to be shutdown and freed twice when the\ndying thread finally closes the file descriptors, causing a use-after-free\nbug.\r\n\r\nOnly cancel the hrtimer if the associated thread is still around. Also add\nthe interface_lock around the resetting of the tlat_var-\u0026gt;kthread.\r\n\r\nNote, this is just a quick fix that can be backported to stable. A real\nfix is to have a better synchronization between the shutdown of old\nthreads and the starting of new ones.(CVE-2024-46845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: rockchip: Resolve unbalanced runtime PM / system PM handling\r\n\r\nCommit e882575efc77 (\u0026quot;spi: rockchip: Suspend and resume the bus during\nNOIRQ_SYSTEM_SLEEP_PM ops\u0026quot;) stopped respecting runtime PM status and\nsimply disabled clocks unconditionally when suspending the system. This\ncauses problems when the device is already runtime suspended when we go\nto sleep -- in which case we double-disable clocks and produce a\nWARNing.\r\n\r\nSwitch back to pm_runtime_force_{suspend,resume}(), because that still\nseems like the right thing to do, and the aforementioned commit makes no\nexplanation why it stopped using it.\r\n\r\nAlso, refactor some of the resume() error handling, because it\u0026apos;s not\nactually a good idea to re-disable clocks on failure.(CVE-2024-46846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: meson: axg-card: fix \u0026apos;use-after-free\u0026apos;\r\n\r\nBuffer \u0026apos;card-\u0026gt;dai_link\u0026apos; is reallocated in \u0026apos;meson_card_reallocate_links()\u0026apos;,\nso move \u0026apos;pad\u0026apos; pointer initialization after this function when memory is\nalready reallocated.\r\n\r\nKasan bug report:\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc\nRead of size 8 at addr ffff000000e8b260 by task modprobe/356\r\n\r\nCPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1\nCall trace:\n dump_backtrace+0x94/0xec\n show_stack+0x18/0x24\n dump_stack_lvl+0x78/0x90\n print_report+0xfc/0x5c0\n kasan_report+0xb8/0xfc\n __asan_load8+0x9c/0xb8\n axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]\n meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]\n platform_probe+0x8c/0xf4\n really_probe+0x110/0x39c\n __driver_probe_device+0xb8/0x18c\n driver_probe_device+0x108/0x1d8\n __driver_attach+0xd0/0x25c\n bus_for_each_dev+0xe0/0x154\n driver_attach+0x34/0x44\n bus_add_driver+0x134/0x294\n driver_register+0xa8/0x1e8\n __platform_driver_register+0x44/0x54\n axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]\n do_one_initcall+0xdc/0x25c\n do_init_module+0x10c/0x334\n load_module+0x24c4/0x26cc\n init_module_from_file+0xd4/0x128\n __arm64_sys_finit_module+0x1f4/0x41c\n invoke_syscall+0x60/0x188\n el0_svc_common.constprop.0+0x78/0x13c\n do_el0_svc+0x30/0x40\n el0_svc+0x38/0x78\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194(CVE-2024-46849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-buf: heaps: Fix off-by-one in CMA heap fault handler\r\n\r\nUntil VM_DONTEXPAND was added in commit 1c1914d6e8c6 (\u0026quot;dma-buf: heaps:\nDon\u0026apos;t track CMA dma-buf pages under RssFile\u0026quot;) it was possible to obtain\na mapping larger than the buffer size via mremap and bypass the overflow\ncheck in dma_buf_mmap_internal. When using such a mapping to attempt to\nfault past the end of the buffer, the CMA heap fault handler also checks\nthe fault offset against the buffer size, but gets the boundary wrong by\n1. Fix the boundary check so that we don\u0026apos;t read off the end of the pages\narray and insert an arbitrary page in the mapping.(CVE-2024-46852)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Fix bridge mode operations when there are no VFs\r\n\r\nCurrently, trying to set the bridge mode attribute when numvfs=0 leads to a\ncrash:\r\n\r\nbridge link set dev eth2 hwmode vepa\r\n\r\n[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[...]\n[  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]\n[...]\n[  168.976037] Call Trace:\n[  168.976188]  \u0026lt;TASK\u0026gt;\n[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]\n[  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]\n[  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0\n[  168.979714]  rtnetlink_rcv_msg+0x159/0x400\n[  168.980451]  netlink_rcv_skb+0x54/0x100\n[  168.980675]  netlink_unicast+0x241/0x360\n[  168.980918]  netlink_sendmsg+0x1f6/0x430\n[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0\n[  168.982155]  ___sys_sendmsg+0x88/0xd0\n[  168.985036]  __sys_sendmsg+0x59/0xa0\n[  168.985477]  do_syscall_64+0x79/0x150\n[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  168.987773] RIP: 0033:0x7f8f7950f917\r\n\r\n(esw-\u0026gt;fdb_table.legacy.vepa_fdb is null)\r\n\r\nThe bridge mode is only relevant when there are multiple functions per\nport. Therefore, prevent setting and getting this setting when there are no\nVFs.\r\n\r\nNote that after this change, there are no settings to change on the PF\ninterface using `bridge link` when there are no VFs, so the interface no\nlonger appears in the `bridge link` output.(CVE-2024-46857)","status":"published","published":"2024-10-12T11:07:41Z","modified":"2026-08-18T01:17:34.355790353Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2024-2255","title":"kernel security update","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/i915/gt: Cleanup partial engine discovery failures\r\n\r\nIf we abort driver initialisation in the middle of gt/engine discovery,\nsome engines will be fully setup and some not. Those incompletely setup\nengines only have \u0026apos;engine-\u0026gt;release == NULL\u0026apos; and so will leak any of the\ncommon objects allocated.\r\n\r\nv2:\n - Drop the destroy_pinned_context() helper for now.  It\u0026apos;s not really\n   worth it with just a single callsite at the moment.  (Janusz)(CVE-2022-48893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to avoid dirent corruption\r\n\r\nAs Al reported in link[1]:\r\n\r\nf2fs_rename()\n...\n\tif (old_dir != new_dir \u0026amp;\u0026amp; !whiteout)\n\t\tf2fs_set_link(old_inode, old_dir_entry,\n\t\t\t\t\told_dir_page, new_dir);\n\telse\n\t\tf2fs_put_page(old_dir_page, 0);\r\n\r\nYou want correct inumber in the \u0026quot;..\u0026quot; link.  And cross-directory\nrename does move the source to new parent, even if you\u0026apos;d been asked\nto leave a whiteout in the old place.\r\n\r\n[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/\r\n\r\nWith below testcase, it may cause dirent corruption, due to it missed\nto call f2fs_set_link() to update \u0026quot;..\u0026quot; link to new directory.\n- mkdir -p dir/foo\n- renameat2 -w dir/foo bar\r\n\r\n[ASSERT] (__chk_dots_dentries:1421)  --\u0026gt; Bad inode number[0x4] for \u0026apos;..\u0026apos;, parent parent ino is [0x3]\n[FSCK] other corrupted bugs                           [Fail](CVE-2023-52444)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefivarfs: force RO when remounting if SetVariable is not supported\r\n\r\nIf SetVariable at runtime is not supported by the firmware we never assign\na callback for that function. At the same time mount the efivarfs as\nRO so no one can call that.  However, we never check the permission flags\nwhen someone remounts the filesystem as RW. As a result this leads to a\ncrash looking like this:\r\n\r\n$ mount -o remount,rw /sys/firmware/efi/efivars\n$ efi-updatevar -f PK.auth PK\r\n\r\n[  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[  303.280482] Mem abort info:\n[  303.280854]   ESR = 0x0000000086000004\n[  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits\n[  303.282016]   SET = 0, FnV = 0\n[  303.282414]   EA = 0, S1PTW = 0\n[  303.282821]   FSC = 0x04: level 0 translation fault\n[  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000\n[  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP\n[  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6\n[  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1\n[  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023\n[  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  303.292123] pc : 0x0\n[  303.292443] lr : efivar_set_variable_locked+0x74/0xec\n[  303.293156] sp : ffff800008673c10\n[  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000\n[  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027\n[  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000\n[  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000\n[  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54\n[  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4\n[  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002\n[  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201\n[  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc\n[  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000\n[  303.303341] Call trace:\n[  303.303679]  0x0\n[  303.303938]  efivar_entry_set_get_size+0x98/0x16c\n[  303.304585]  efivarfs_file_write+0xd0/0x1a4\n[  303.305148]  vfs_write+0xc4/0x2e4\n[  303.305601]  ksys_write+0x70/0x104\n[  303.306073]  __arm64_sys_write+0x1c/0x28\n[  303.306622]  invoke_syscall+0x48/0x114\n[  303.307156]  el0_svc_common.constprop.0+0x44/0xec\n[  303.307803]  do_el0_svc+0x38/0x98\n[  303.308268]  el0_svc+0x2c/0x84\n[  303.308702]  el0t_64_sync_handler+0xf4/0x120\n[  303.309293]  el0t_64_sync+0x190/0x194\n[  303.309794] Code: ???????? ???????? ???????? ???????? (????????)\n[  303.310612] ---[ end trace 0000000000000000 ]---\r\n\r\nFix this by adding a .reconfigure() function to the fs operations which\nwe can use to check the requested flags and deny anything that\u0026apos;s not RO\nif the firmware doesn\u0026apos;t implement SetVariable at runtime.(CVE-2023-52463)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/srso: Add SRSO mitigation for Hygon processors\r\n\r\nAdd mitigation for the speculative return stack overflow vulnerability\nwhich exists on Hygon processors too.(CVE-2023-52482)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: scomp - fix req-\u0026gt;dst buffer overflow\r\n\r\nThe req-\u0026gt;dst buffer size should be checked before copying from the\nscomp_scratch-\u0026gt;dst to avoid req-\u0026gt;dst buffer overflow problem.(CVE-2023-52612)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: verify mac len before reading mac header\r\n\r\nLLC reads the mac header with eth_hdr without verifying that the skb\nhas an Ethernet header.\r\n\r\nSyzbot was able to enter llc_rcv on a tun device. Tun can insert\npackets without mac len and with user configurable skb-\u0026gt;protocol\n(passing a tun_pi header when not configuring IFF_NO_PI).\r\n\r\n    BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n    BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n    llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n    llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n    llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218\n    __netif_receive_skb_one_core net/core/dev.c:5523 [inline]\n    __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637\n    netif_receive_skb_internal net/core/dev.c:5723 [inline]\n    netif_receive_skb+0x58/0x660 net/core/dev.c:5782\n    tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n    tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002\r\n\r\nAdd a mac_len test before all three eth_hdr(skb) calls under net/llc.\r\n\r\nThere are further uses in include/net/llc_pdu.h. All these are\nprotected by a test skb-\u0026gt;protocol == ETH_P_802_2. Which does not\nprotect against this tun scenario.\r\n\r\nBut the mac_len test added in this patch in llc_fixup_skb will\nindirectly protect those too. That is called from llc_rcv before any\nother LLC code.\r\n\r\nIt is tempting to just add a blanket mac_len check in llc_rcv, but\nnot sure whether that could break valid LLC paths that do not assume\nan Ethernet header. 802.2 LLC may be used on top of non-802.3\nprotocols in principle. The below referenced commit shows that used\nto, on top of Token Ring.\r\n\r\nAt least one of the three eth_hdr uses goes back to before the start\nof git history. But the one that syzbot exercises is introduced in\nthis commit. That commit is old enough (2008), that effectively all\nstable kernels should receive this.(CVE-2023-52843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed\r\n\r\nIf hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER\nhandler cannot perform VF register successfully as the register call\nis received before netvsc_probe is finished. This is because we\nregister register_netdevice_notifier() very early( even before\nvmbus_driver_register()).\nTo fix this, we try to register each such matching VF( if it is visible\nas a netdevice) at the end of netvsc_probe.(CVE-2024-26820)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: honor table dormant flag from netdev release event path\r\n\r\nCheck for table dormant flag otherwise netdev release event path tries\nto unregister an already unregistered hook.\r\n\r\n[524854.857999] ------------[ cut here ]------------\n[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260\n[...]\n[524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365\n[524854.858869] Workqueue: netns cleanup_net\n[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260\n[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff \u0026lt;0f\u0026gt; 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41\n[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246\n[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a\n[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438\n[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34\n[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005\n[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00\n[524854.858971] FS:  0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[524854.858982] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0\n[524854.859000] Call Trace:\n[524854.859006]  \u0026lt;TASK\u0026gt;\n[524854.859013]  ? __warn+0x9f/0x1a0\n[524854.859027]  ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859044]  ? report_bug+0x1b1/0x1e0\n[524854.859060]  ? handle_bug+0x3c/0x70\n[524854.859071]  ? exc_invalid_op+0x17/0x40\n[524854.859083]  ? asm_exc_invalid_op+0x1a/0x20\n[524854.859100]  ? __nf_unregister_net_hook+0x6a/0x260\n[524854.859116]  ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859135]  nf_tables_netdev_event+0x337/0x390 [nf_tables]\n[524854.859304]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859461]  ? packet_notifier+0xb3/0x360\n[524854.859476]  ? _raw_spin_unlock_irqrestore+0x11/0x40\n[524854.859489]  ? dcbnl_netdevice_event+0x35/0x140\n[524854.859507]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859661]  notifier_call_chain+0x7d/0x140\n[524854.859677]  unregister_netdevice_many_notify+0x5e1/0xae0(CVE-2024-36005)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix uninitialized ratelimit_state-\u0026gt;lock access in __ext4_fill_super()\r\n\r\nIn the following concurrency we will access the uninitialized rs-\u0026gt;lock:\r\n\r\next4_fill_super\n  ext4_register_sysfs\n   // sysfs registered msg_ratelimit_interval_ms\n                             // Other processes modify rs-\u0026gt;interval to\n                             // non-zero via msg_ratelimit_interval_ms\n  ext4_orphan_cleanup\n    ext4_msg(sb, KERN_INFO, \u0026quot;Errors on filesystem, \u0026quot;\n      __ext4_msg\n        ___ratelimit(\u0026amp;(EXT4_SB(sb)-\u0026gt;s_msg_ratelimit_state)\n          if (!rs-\u0026gt;interval)  // do nothing if interval is 0\n            return 1;\n          raw_spin_trylock_irqsave(\u0026amp;rs-\u0026gt;lock, flags)\n            raw_spin_trylock(lock)\n              _raw_spin_trylock\n                __raw_spin_trylock\n                  spin_acquire(\u0026amp;lock-\u0026gt;dep_map, 0, 1, _RET_IP_)\n                    lock_acquire\n                      __lock_acquire\n                        register_lock_class\n                          assign_lock_key\n                            dump_stack();\n  ratelimit_state_init(\u0026amp;sbi-\u0026gt;s_msg_ratelimit_state, 5 * HZ, 10);\n    raw_spin_lock_init(\u0026amp;rs-\u0026gt;lock);\n    // init rs-\u0026gt;lock here\r\n\r\nand get the following dump_stack:\r\n\r\n=========================================================\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0026apos;t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504\n[...]\nCall Trace:\n dump_stack_lvl+0xc5/0x170\n dump_stack+0x18/0x30\n register_lock_class+0x740/0x7c0\n __lock_acquire+0x69/0x13a0\n lock_acquire+0x120/0x450\n _raw_spin_trylock+0x98/0xd0\n ___ratelimit+0xf6/0x220\n __ext4_msg+0x7f/0x160 [ext4]\n ext4_orphan_cleanup+0x665/0x740 [ext4]\n __ext4_fill_super+0x21ea/0x2b10 [ext4]\n ext4_fill_super+0x14d/0x360 [ext4]\n[...]\n=========================================================\r\n\r\nNormally interval is 0 until s_msg_ratelimit_state is initialized, so\n___ratelimit() does nothing. But registering sysfs precedes initializing\nrs-\u0026gt;lock, so it is possible to change rs-\u0026gt;interval to a non-zero value\nvia the msg_ratelimit_interval_ms interface of sysfs while rs-\u0026gt;lock is\nuninitialized, and then a call to ext4_msg triggers the problem by\naccessing an uninitialized rs-\u0026gt;lock. Therefore register sysfs after all\ninitializations are complete to avoid such problems.(CVE-2024-40998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\r\n\r\nset_memory_rox() can fail, leaving memory unprotected.\r\n\r\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.(CVE-2024-42067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nexthop: Initialize all fields in dumped nexthops\r\n\r\nstruct nexthop_grp contains two reserved fields that are not initialized by\nnla_put_nh_group(), and carry garbage. This can be observed e.g. with\nstrace (edited for clarity):\r\n\r\n    # ip nexthop add id 1 dev lo\n    # ip nexthop add id 101 group 1\n    # strace -e recvmsg ip nexthop get id 101\n    ...\n    recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},\n                 [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52\r\n\r\nThe fields are reserved and therefore not currently used. But as they are, they\nleak kernel memory, and the fact they are not just zero complicates repurposing\nof the fields for new ends. Initialize the full structure.(CVE-2024-42283)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nirqchip/imx-irqsteer: Handle runtime power management correctly\r\n\r\nThe power domain is automatically activated from clk_prepare(). However, on\ncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes\nsleeping functions, which triggers the \u0026apos;scheduling while atomic\u0026apos; bug in the\ncontext switch path during device probing:\r\n\r\n BUG: scheduling while atomic: kworker/u13:1/48/0x00000002\n Call trace:\n  __schedule_bug+0x54/0x6c\n  __schedule+0x7f0/0xa94\n  schedule+0x5c/0xc4\n  schedule_preempt_disabled+0x24/0x40\n  __mutex_lock.constprop.0+0x2c0/0x540\n  __mutex_lock_slowpath+0x14/0x20\n  mutex_lock+0x48/0x54\n  clk_prepare_lock+0x44/0xa0\n  clk_prepare+0x20/0x44\n  imx_irqsteer_resume+0x28/0xe0\n  pm_generic_runtime_resume+0x2c/0x44\n  __genpd_runtime_resume+0x30/0x80\n  genpd_runtime_resume+0xc8/0x2c0\n  __rpm_callback+0x48/0x1d8\n  rpm_callback+0x6c/0x78\n  rpm_resume+0x490/0x6b4\n  __pm_runtime_resume+0x50/0x94\n  irq_chip_pm_get+0x2c/0xa0\n  __irq_do_set_handler+0x178/0x24c\n  irq_set_chained_handler_and_data+0x60/0xa4\n  mxc_gpio_probe+0x160/0x4b0\r\n\r\nCure this by implementing the irq_bus_lock/sync_unlock() interrupt chip\ncallbacks and handle power management in them as they are invoked from\nnon-atomic context.\r\n\r\n[ tglx: Rewrote change log, added Fixes tag ](CVE-2024-42290)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid using corrupted block bitmap buffer\r\n\r\nWhen the filesystem block bitmap is corrupted, we detect the corruption\nwhile loading the bitmap and fail the allocation with error. However the\nnext allocation from the same bitmap will notice the bitmap buffer is\nalready loaded and tries to allocate from the bitmap with mixed results\n(depending on the exact nature of the bitmap corruption). Fix the\nproblem by using BH_verified bit to indicate whether the bitmap is valid\nor not.(CVE-2024-42306)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes\r\n\r\nIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42309)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: venus: fix use after free in vdec_close\r\n\r\nThere appears to be a possible use after free with vdec_close().\nThe firmware will add buffer release work to the work queue through\nHFI callbacks as a normal part of decoding. Randomly closing the\ndecoder device from userspace during normal decoding can incur\na read after free for inst.\r\n\r\nFix it by cancelling the work in vdec_close.(CVE-2024-42313)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvs: properly dereference pe in ip_vs_add_service\r\n\r\nUse pe directly to resolve sparse warning:\r\n\r\n  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()\r\n\r\nIf IORESOURCE_MEM is not provided in Device Tree due to\nany error, resource_list_first_type() will return NULL and\npci_parse_request_of_pci_ranges() will just emit a warning.\r\n\r\nThis will cause a NULL pointer dereference. Fix this bug by adding NULL\nreturn check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: trigger: Unregister sysfs attributes before calling deactivate()\r\n\r\nTriggers which have trigger specific sysfs attributes typically store\nrelated data in trigger-data allocated by the activate() callback and\nfreed by the deactivate() callback.\r\n\r\nCalling device_remove_groups() after calling deactivate() leaves a window\nwhere the sysfs attributes show/store functions could be called after\ndeactivation and then operate on the just freed trigger-data.\r\n\r\nMove the device_remove_groups() call to before deactivate() to close\nthis race window.\r\n\r\nThis also makes the deactivation path properly do things in reverse order\nof the activation path which calls the activate() callback before calling\ndevice_add_groups().(CVE-2024-43830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG\r\n\r\nWhen BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls\n__bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them\nthe struct bpf_tramp_image *im pointer as an argument in R0.\r\n\r\nThe trampoline generation code uses emit_addr_mov_i64() to emit\ninstructions for moving the bpf_tramp_image address into R0, but\nemit_addr_mov_i64() assumes the address to be in the vmalloc() space\nand uses only 48 bits. Because bpf_tramp_image is allocated using\nkzalloc(), its address can use more than 48-bits, in this case the\ntrampoline will pass an invalid address to __bpf_tramp_enter/exit()\ncausing a kernel crash.\r\n\r\nFix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64()\nas it can work with addresses that are greater than 48-bits.(CVE-2024-43840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix deadlock between mddev_suspend and flush bio\r\n\r\nDeadlock occurs when mddev is being suspended while some flush bio is in\nprogress. It is a complex issue.\r\n\r\nT1. the first flush is at the ending stage, it clears \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;\n    and tries to submit data, but is blocked because mddev is suspended\n    by T4.\nT2. the second flush sets \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;, and attempts to queue\n    md_submit_flush_data(), which is already running (T1) and won\u0026apos;t\n    execute again if on the same CPU as T1.\nT3. the third flush inc active_io and tries to flush, but is blocked because\n    \u0026apos;mddev-\u0026gt;flush_bio\u0026apos; is not NULL (set by T2).\nT4. mddev_suspend() is called and waits for active_io dec to 0 which is inc\n    by T3.\r\n\r\n  T1\t\tT2\t\tT3\t\tT4\n  (flush 1)\t(flush 2)\t(third 3)\t(suspend)\n  md_submit_flush_data\n   mddev-\u0026gt;flush_bio = NULL;\n   .\n   .\t \tmd_flush_request\n   .\t  \t mddev-\u0026gt;flush_bio = bio\n   .\t  \t queue submit_flushes\n   .\t\t .\n   .\t\t .\t\tmd_handle_request\n   .\t\t .\t\t active_io + 1\n   .\t\t .\t\t md_flush_request\n   .\t\t .\t\t  wait !mddev-\u0026gt;flush_bio\n   .\t\t .\n   .\t\t .\t\t\t\tmddev_suspend\n   .\t\t .\t\t\t\t wait !active_io\n   .\t\t .\n   .\t\t submit_flushes\n   .\t\t queue_work md_submit_flush_data\n   .\t\t //md_submit_flush_data is already running (T1)\n   .\n   md_handle_request\n    wait resume\r\n\r\nThe root issue is non-atomic inc/dec of active_io during flush process.\nactive_io is dec before md_submit_flush_data is queued, and inc soon\nafter md_submit_flush_data() run.\n  md_flush_request\n    active_io + 1\n    submit_flushes\n      active_io - 1\n      md_submit_flush_data\n        md_handle_request\n        active_io + 1\n          make_request\n        active_io - 1\r\n\r\nIf active_io is dec after md_handle_request() instead of within\nsubmit_flushes(), make_request() can be called directly intead of\nmd_handle_request() in md_submit_flush_data(), and active_io will\nonly inc and dec once in the whole flush process. Deadlock will be\nfixed.\r\n\r\nAdditionally, the only difference between fixing the issue and before is\nthat there is no return error handling of make_request(). But after\nprevious patch cleaned md_write_start(), make_requst() only return error\nin raid5_make_request() by dm-raid, see commit 41425f96d7aa (\u0026quot;dm-raid456,\nmd/raid456: fix a deadlock for dm-raid456 while io concurrent with\nreshape)\u0026quot;. Since dm always splits data and flush operation into two\nseparate io, io size of flush submitted by dm always is 0, make_request()\nwill not be called in md_submit_flush_data(). To prevent future\nmodifications from introducing issues, add WARN_ON to ensure\nmake_request() no error is returned in this context.(CVE-2024-43855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/hns: Fix soft lockup under heavy CEQE load\r\n\r\nCEQEs are handled in interrupt handler currently. This may cause the\nCPU core staying in interrupt context too long and lead to soft lockup\nunder heavy load.\r\n\r\nHandle CEQEs in BH workqueue and set an upper limit for the number of\nCEQE handled by a single call of work handler.(CVE-2024-43872)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg: protect concurrent access to mem_cgroup_idr\r\n\r\nCommit 73f576c04b94 (\u0026quot;mm: memcontrol: fix cgroup creation failure after\nmany small jobs\u0026quot;) decoupled the memcg IDs from the CSS ID space to fix the\ncgroup creation failures.  It introduced IDR to maintain the memcg ID\nspace.  The IDR depends on external synchronization mechanisms for\nmodifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()\nhappen within css callback and thus are protected through cgroup_mutex\nfrom concurrent modifications.  However idr_remove() for mem_cgroup_idr\nwas not protected against concurrency and can be run concurrently for\ndifferent memcgs when they hit their refcnt to zero.  Fix that.\r\n\r\nWe have been seeing list_lru based kernel crashes at a low frequency in\nour fleet for a long time.  These crashes were in different part of\nlist_lru code including list_lru_add(), list_lru_del() and reparenting\ncode.  Upon further inspection, it looked like for a given object (dentry\nand inode), the super_block\u0026apos;s list_lru didn\u0026apos;t have list_lru_one for the\nmemcg of that object.  The initial suspicions were either the object is\nnot allocated through kmem_cache_alloc_lru() or somehow\nmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but\nreturned success.  No evidence were found for these cases.\r\n\r\nLooking more deeply, we started seeing situations where valid memcg\u0026apos;s id\nis not present in mem_cgroup_idr and in some cases multiple valid memcgs\nhave same id and mem_cgroup_idr is pointing to one of them.  So, the most\nreasonable explanation is that these situations can happen due to race\nbetween multiple idr_remove() calls or race between\nidr_alloc()/idr_replace() and idr_remove().  These races are causing\nmultiple memcgs to acquire the same ID and then offlining of one of them\nwould cleanup list_lrus on the system for all of them.  Later access from\nother memcgs to the list_lru cause crashes due to missing list_lru_one.(CVE-2024-43892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: core: check uartclk for zero to avoid divide by zero\r\n\r\nCalling ioctl TIOCSSERIAL with an invalid baud_base can\nresult in uartclk being zero, which will result in a\ndivide by zero error in uart_get_divisor(). The check for\nuartclk being zero in uart_set_info() needs to be done\nbefore other settings are made as subsequent calls to\nioctl TIOCSSERIAL for the same port would be impacted if\nthe uartclk check was done where uartclk gets set.\r\n\r\nOops: divide error: 0000  PREEMPT SMP KASAN PTI\nRIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)\nCall Trace:\n \u0026lt;TASK\u0026gt;\nserial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576\n    drivers/tty/serial/8250/8250_port.c:2589)\nserial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502\n    drivers/tty/serial/8250/8250_port.c:2741)\nserial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)\nuart_change_line_settings (./include/linux/spinlock.h:376\n    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)\nuart_port_startup (drivers/tty/serial/serial_core.c:342)\nuart_startup (drivers/tty/serial/serial_core.c:368)\nuart_set_info (drivers/tty/serial/serial_core.c:1034)\nuart_set_info_user (drivers/tty/serial/serial_core.c:1059)\ntty_set_serial (drivers/tty/tty_io.c:2637)\ntty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)\n__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907\n    fs/ioctl.c:893 fs/ioctl.c:893)\ndo_syscall_64 (arch/x86/entry/common.c:52\n    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nRule: add(CVE-2024-43893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfou: remove warn in gue_gro_receive on unsupported protocol\r\n\r\nDrop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is\nnot known or does not have a GRO handler.\r\n\r\nSuch a packet is easily constructed. Syzbot generates them and sets\noff this warning.\r\n\r\nRemove the warning as it is expected and not actionable.\r\n\r\nThe warning was previously reduced from WARN_ON to WARN_ON_ONCE in\ncommit 270136613bf7 (\u0026quot;fou: Do WARN_ON_ONCE in gue_gro_receive for bad\nproto callbacks\u0026quot;).(CVE-2024-44940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: line6: Fix racy access to midibuf\r\n\r\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\r\n\r\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races.(CVE-2024-44954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natm: idt77252: prevent use after free in dequeue_rx()\r\n\r\nWe can\u0026apos;t dereference \u0026quot;skb\u0026quot; after calling vcc-\u0026gt;push() because the skb\nis released.(CVE-2024-44998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix Panther point NULL pointer deref at full-speed re-enumeration\r\n\r\nre-enumerating full-speed devices after a failed address device command\ncan trigger a NULL pointer dereference.\r\n\r\nFull-speed devices may need to reconfigure the endpoint 0 Max Packet Size\nvalue during enumeration. Usb core calls usb_ep0_reinit() in this case,\nwhich ends up calling xhci_configure_endpoint().\r\n\r\nOn Panther point xHC the xhci_configure_endpoint() function will\nadditionally check and reserve bandwidth in software. Other hosts do\nthis in hardware\r\n\r\nIf xHC address device command fails then a new xhci_virt_device structure\nis allocated as part of re-enabling the slot, but the bandwidth table\npointers are not set up properly here.\nThis triggers the NULL pointer dereference the next time usb_ep0_reinit()\nis called and xhci_configure_endpoint() tries to check and reserve\nbandwidth\r\n\r\n[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd\n[46710.713699] usb 3-1: Device not responding to setup address.\n[46710.917684] usb 3-1: Device not responding to setup address.\n[46711.125536] usb 3-1: device not accepting address 5, error -71\n[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[46711.125600] #PF: supervisor read access in kernel mode\n[46711.125603] #PF: error_code(0x0000) - not-present page\n[46711.125606] PGD 0 P4D 0\n[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI\n[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1\n[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.\n[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]\n[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c\r\n\r\nFix this by making sure bandwidth table pointers are set up correctly\nafter a failed address device command, and additionally by avoiding\nchecking for bandwidth in cases like this where no actual endpoints are\nadded or removed, i.e. only context for default control endpoint 0 is\nevaluated.(CVE-2024-45006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix error recovery leading to data corruption on ESE devices\r\n\r\nExtent Space Efficient (ESE) or thin provisioned volumes need to be\nformatted on demand during usual IO processing.\r\n\r\nThe dasd_ese_needs_format function checks for error codes that signal\nthe non existence of a proper track format.\r\n\r\nThe check for incorrect length is to imprecise since other error cases\nleading to transport of insufficient data also have this flag set.\nThis might lead to data corruption in certain error cases for example\nduring a storage server warmstart.\r\n\r\nFix by removing the check for incorrect length and replacing by\nexplicitly checking for invalid track format in transport mode.\r\n\r\nAlso remove the check for file protected since this is not a valid\nESE handling case.(CVE-2024-45026)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: pn533: Add poll mod list filling check\r\n\r\nIn case of im_protocols value is 1 and tm_protocols value is 0 this\ncombination successfully passes the check\n\u0026apos;if (!im_protocols \u0026amp;\u0026amp; !tm_protocols)\u0026apos; in the nfc_start_poll().\nBut then after pn533_poll_create_mod_list() call in pn533_start_poll()\npoll mod list will remain empty and dev-\u0026gt;poll_mod_count will remain 0\nwhich lead to division by zero.\r\n\r\nNormally no im protocol has value 1 in the mask, so this combination is\nnot expected by driver. But these protocol values actually come from\nuserspace via Netlink interface (NFC_CMD_START_POLL operation). So a\nbroken or malicious program may pass a message containing a \u0026quot;bad\u0026quot;\ncombination of protocol parameter values so that dev-\u0026gt;poll_mod_count\nis not incremented inside pn533_poll_create_mod_list(), thus leading\nto division by zero.\nCall trace looks like:\nnfc_genl_start_poll()\n  nfc_start_poll()\n    -\u0026gt;start_poll()\n    pn533_start_poll()\r\n\r\nAdd poll mod list filling check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: ucsi: Fix null pointer dereference in trace\r\n\r\nucsi_register_altmode checks IS_ERR for the alt pointer and treats\nNULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,\nucsi_register_displayport returns NULL which causes a NULL pointer\ndereference in trace. Rather than return NULL, call\ntypec_port_register_altmode to register DisplayPort alternate mode\nas a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Remove tst_run from lwt_seg6local_prog_ops.\r\n\r\nThe syzbot reported that the lwt_seg6 related BPF ops can be invoked\nvia bpf_test_run() without without entering input_action_end_bpf()\nfirst.\r\n\r\nMartin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL\nprobably didn\u0026apos;t work since it was introduced in commit 04d4b274e2a\n(\u0026quot;ipv6: sr: Add seg6local action End.BPF\u0026quot;). The reason is that the\nper-CPU variable seg6_bpf_srh_states::srh is never assigned in the self\ntest case but each BPF function expects it.\r\n\r\nRemove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.(CVE-2024-46754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Add netif_device_attach/detach into PF reset flow\r\n\r\nEthtool callbacks can be executed while reset is in progress and try to\naccess deleted resources, e.g. getting coalesce settings can result in a\nNULL pointer dereference seen below.\r\n\r\nReproduction steps:\nOnce the driver is fully initialized, trigger reset:\n\t# echo 1 \u0026gt; /sys/class/net/\u0026lt;interface\u0026gt;/device/reset\nwhen reset is in progress try to get coalesce settings using ethtool:\n\t# ethtool -c \u0026lt;interface\u0026gt;\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000020\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP PTI\nCPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7\nRIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]\nRSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206\nRAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000\nR13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40\nFS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0\nCall Trace:\n\u0026lt;TASK\u0026gt;\nice_get_coalesce+0x17/0x30 [ice]\ncoalesce_prepare_data+0x61/0x80\nethnl_default_doit+0xde/0x340\ngenl_family_rcv_msg_doit+0xf2/0x150\ngenl_rcv_msg+0x1b3/0x2c0\nnetlink_rcv_skb+0x5b/0x110\ngenl_rcv+0x28/0x40\nnetlink_unicast+0x19c/0x290\nnetlink_sendmsg+0x222/0x490\n__sys_sendto+0x1df/0x1f0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x82/0x160\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7faee60d8e27\r\n\r\nCalling netif_device_detach() before reset makes the net core not call\nthe driver when ethtool command is issued, the attempt to execute an\nethtool command during reset will result in the following message:\r\n\r\n    netlink error: No such device\r\n\r\ninstead of NULL pointer dereference. Once reset is done and\nice_rebuild() is executing, the netif_device_attach() is called to allow\nfor ethtool operations to occur again in a safe manner.(CVE-2024-46770)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: unset the binding mark of a reused connection\r\n\r\nSteve French reported null pointer dereference error from sha256 lib.\ncifs.ko can send session setup requests on reused connection.\nIf reused connection is used for binding session, conn-\u0026gt;binding can\nstill remain true and generate_preauth_hash() will not set\nsess-\u0026gt;Preauth_HashValue and it will be NULL.\nIt is used as a material to create an encryption key in\nksmbd_gen_smb311_encryptionkey. -\u0026gt;Preauth_HashValue cause null pointer\ndereference error from crypto_shash_update().\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 8 PID: 429254 Comm: kworker/8:39\nHardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )\nWorkqueue: ksmbd-io handle_ksmbd_work [ksmbd]\nRIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n\u0026lt;TASK\u0026gt;\n? show_regs+0x6d/0x80\n? __die+0x24/0x80\n? page_fault_oops+0x99/0x1b0\n? do_user_addr_fault+0x2ee/0x6b0\n? exc_page_fault+0x83/0x1b0\n? asm_exc_page_fault+0x27/0x30\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n_sha256_update+0x77/0xa0 [sha256_ssse3]\nsha256_avx2_update+0x15/0x30 [sha256_ssse3]\ncrypto_shash_update+0x1e/0x40\nhmac_update+0x12/0x20\ncrypto_shash_update+0x1e/0x40\ngenerate_key+0x234/0x380 [ksmbd]\ngenerate_smb3encryptionkey+0x40/0x1c0 [ksmbd]\nksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]\nntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]\nsmb2_sess_setup+0x952/0xaa0 [ksmbd]\n__process_request+0xa3/0x1d0 [ksmbd]\n__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]\nhandle_ksmbd_work+0x2d/0xa0 [ksmbd]\nprocess_one_work+0x16c/0x350\nworker_thread+0x306/0x440\n? __pfx_worker_thread+0x10/0x10\nkthread+0xef/0x120\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x44/0x70\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1b/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2024-46795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: the warning dereferencing obj for nbio_v7_4\r\n\r\nif ras_manager obj null, don\u0026apos;t print NBIO err data(CVE-2024-46819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nELF: fix kernel.randomize_va_space double read\r\n\r\nELF loader uses \u0026quot;randomize_va_space\u0026quot; twice. It is sysctl and can change\nat any moment, so 2 loads could see 2 different values in theory with\nunpredictable consequences.\r\n\r\nIssue exactly one load for consistent value across one exec.(CVE-2024-46826)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched: sch_cake: fix bulk flow accounting logic for host fairness\r\n\r\nIn sch_cake, we keep track of the count of active bulk flows per host,\nwhen running in dst/src host fairness mode, which is used as the\nround-robin weight when iterating through flows. The count of active\nbulk flows is updated whenever a flow changes state.\r\n\r\nThis has a peculiar interaction with the hash collision handling: when a\nhash collision occurs (after the set-associative hashing), the state of\nthe hash bucket is simply updated to match the new packet that collided,\nand if host fairness is enabled, that also means assigning new per-host\nstate to the flow. For this reason, the bulk flow counters of the\nhost(s) assigned to the flow are decremented, before new state is\nassigned (and the counters, which may not belong to the same host\nanymore, are incremented again).\r\n\r\nBack when this code was introduced, the host fairness mode was always\nenabled, so the decrement was unconditional. When the configuration\nflags were introduced the *increment* was made conditional, but\nthe *decrement* was not. Which of course can lead to a spurious\ndecrement (and associated wrap-around to U16_MAX).\r\n\r\nAFAICT, when host fairness is disabled, the decrement and wrap-around\nhappens as soon as a hash collision occurs (which is not that common in\nitself, due to the set-associative hashing). However, in most cases this\nis harmless, as the value is only used when host fairness mode is\nenabled. So in order to trigger an array overflow, sch_cake has to first\nbe configured with host fairness disabled, and while running in this\nmode, a hash collision has to occur to cause the overflow. Then, the\nqdisc has to be reconfigured to enable host fairness, which leads to the\narray out-of-bounds because the wrapped-around value is retained and\nused as an array index. It seems that syzbot managed to trigger this,\nwhich is quite impressive in its own right.\r\n\r\nThis patch fixes the issue by introducing the same conditional check on\ndecrement as is used on increment.\r\n\r\nThe original bug predates the upstreaming of cake, but the commit listed\nin the Fixes tag touched that code, meaning that this patch won\u0026apos;t apply\nbefore that.(CVE-2024-46828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: clean up our handling of refs == 0 in snapshot delete\r\n\r\nIn reada we BUG_ON(refs == 0), which could be unkind since we aren\u0026apos;t\nholding a lock on the extent leaf and thus could get a transient\nincorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which\ncould happen if we have extent tree corruption.  Change that to return\n-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,\nhowever we return -EIO, which -EUCLEAN is a more appropriate error code.\nFinally in walk_up_proc we have the same BUG_ON(refs == 0), so convert\nthat to proper error handling.  Also adjust the error message so we can\nactually do something with the information.(CVE-2024-46840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/x86/intel: Limit the period on Haswell\r\n\r\nRunning the ltp test cve-2015-3290 concurrently reports the following\nwarnings.\r\n\r\nperfevents: irq loop stuck!\n  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174\n  intel_pmu_handle_irq+0x285/0x370\n  Call Trace:\n   \u0026lt;NMI\u0026gt;\n   ? __warn+0xa4/0x220\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? __report_bug+0x123/0x130\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? __report_bug+0x123/0x130\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? report_bug+0x3e/0xa0\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x50\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? irq_work_claim+0x1e/0x40\n   ? intel_pmu_handle_irq+0x285/0x370\n   perf_event_nmi_handler+0x3d/0x60\n   nmi_handle+0x104/0x330\r\n\r\nThanks to Thomas Gleixner\u0026apos;s analysis, the issue is caused by the low\ninitial period (1) of the frequency estimation algorithm, which triggers\nthe defects of the HW, specifically erratum HSW11 and HSW143. (For the\ndetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)\r\n\r\nThe HSW11 requires a period larger than 100 for the INST_RETIRED.ALL\nevent, but the initial period in the freq mode is 1. The erratum is the\nsame as the BDM11, which has been supported in the kernel. A minimum\nperiod of 128 is enforced as well on HSW.\r\n\r\nHSW143 is regarding that the fixed counter 1 may overcount 32 with the\nHyper-Threading is enabled. However, based on the test, the hardware\nhas more issues than it tells. Besides the fixed counter 1, the message\n\u0026apos;interrupt took too long\u0026apos; can be observed on any counter which was armed\nwith a period \u0026lt; 32 and two events expired in the same NMI. A minimum\nperiod of 32 is enforced for the rest of the events.\nThe recommended workaround code of the HSW143 is not implemented.\nBecause it only addresses the issue for the fixed counter. It brings\nextra overhead through extra MSR writing. No related overcounting issue\nhas been reported so far.(CVE-2024-46848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dpaa: Pad packets to ETH_ZLEN\r\n\r\nWhen sending packets under 60 bytes, up to three bytes of the buffer\nfollowing the data may be leaked. Avoid this by extending all packets to\nETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be\nreproduced by running\r\n\r\n\t$ ping -s 11 destination(CVE-2024-46854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_socket: fix sk refcount leaks\r\n\r\nWe must put \u0026apos;sk\u0026apos; reference before returning.(CVE-2024-46855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: Fix uaf in __timer_delete_sync\r\n\r\nThere are two paths to access mptcp_pm_del_add_timer, result in a race\ncondition:\r\n\r\n     CPU1\t\t\t\tCPU2\n     ====                               ====\n     net_rx_action\n     napi_poll                          netlink_sendmsg\n     __napi_poll                        netlink_unicast\n     process_backlog                    netlink_unicast_kernel\n     __netif_receive_skb                genl_rcv\n     __netif_receive_skb_one_core       netlink_rcv_skb\n     NF_HOOK                            genl_rcv_msg\n     ip_local_deliver_finish            genl_family_rcv_msg\n     ip_protocol_deliver_rcu            genl_family_rcv_msg_doit\n     tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit\n     tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list\n     tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows\n     tcp_data_queue                     remove_anno_list_by_saddr\n     mptcp_incoming_options             mptcp_pm_del_add_timer\n     mptcp_pm_del_add_timer             kfree(entry)\r\n\r\nIn remove_anno_list_by_saddr(running on CPU2), after leaving the critical\nzone protected by \u0026quot;pm.lock\u0026quot;, the entry will be released, which leads to the\noccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).\r\n\r\nKeeping a reference to add_timer inside the lock, and calling\nsk_stop_timer_sync() with this reference, instead of \u0026quot;entry-\u0026gt;add_timer\u0026quot;.\r\n\r\nMove list_del(\u0026amp;entry-\u0026gt;list) to mptcp_pm_del_add_timer and inside the pm lock,\ndo not directly access any members of the entry outside the pm lock, which\ncan avoid similar \u0026quot;entry-\u0026gt;x\u0026quot; uaf.(CVE-2024-46858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: stm32/cryp - call finalize with bh disabled\r\n\r\nThe finalize operation in interrupt mode produce a produces a spinlock\nrecursion warning. The reason is the fact that BH must be disabled\nduring this process.(CVE-2024-47658)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware\r\n\r\nIf the value of max_speed_hz is 0, it may cause a division by zero\nerror in hisi_calc_effective_speed().\nThe value of max_speed_hz is provided by firmware.\nFirmware is generally considered as a trusted domain. However, as\ndivision by zero errors can cause system failure, for defense measure,\nthe value of max_speed is validated here. So 0 is regarded as invalid\nand an error code is returned.(CVE-2024-47664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_xattr_find_entry()\r\n\r\nAdd a paranoia check to make sure it doesn\u0026apos;t stray beyond valid memory\nregion containing ocfs2 xattr entries when scanning for a match.  It will\nprevent out-of-bound access in case of crafted images.(CVE-2024-47670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usbtmc: prevent kernel-usb-infoleak\r\n\r\nThe syzbot reported a kernel-usb-infoleak in usbtmc_write,\nwe need to clear the structure before filling fields.(CVE-2024-47671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: don\u0026apos;t wait for tx queues if firmware is dead\r\n\r\nThere is a WARNING in iwl_trans_wait_tx_queues_empty() (that was\nrecently converted from just a message), that can be hit if we\nwait for TX queues to become empty after firmware died. Clearly,\nwe can\u0026apos;t expect anything from the firmware after it\u0026apos;s declared dead.\r\n\r\nDon\u0026apos;t call iwl_trans_wait_tx_queues_empty() in this case. While it could\nbe a good idea to stop the flow earlier, the flush functions do some\nmaintenance work that is not related to the firmware, so keep that part\nof the code running even when the firmware is not running.\r\n\r\n[edit commit message](CVE-2024-47672)","status":"published","published":"2024-10-18T11:07:43Z","modified":"2026-08-18T01:18:37.568583109Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2024-2257","title":"kernel security update","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\ni40e: Fix kernel crash during module removal\r\n\r\nThe driver incorrectly frees client instance and subsequent\ni40e module removal leads to kernel crash.\r\n\r\nReproducer:\n1. Do ethtool offline test followed immediately by another one\nhost# ethtool -t eth0 offline; ethtool -t eth0 offline\n2. Remove recursively irdma module that also removes i40e module\nhost# modprobe -r irdma\r\n\r\nResult:\n[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting\n[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished\n[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting\n[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished\n[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110\n[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2\n[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01\n[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1\n[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[ 8687.768755] #PF: supervisor read access in kernel mode\n[ 8687.773895] #PF: error_code(0x0000) - not-present page\n[ 8687.779034] PGD 0 P4D 0\n[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G        W I        5.19.0+ #2\n[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019\n[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e]\n[ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb \u0026lt;48\u0026gt; 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b\n[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202\n[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000\n[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000\n[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000\n[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0\n[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008\n[ 8687.870342] FS:  00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000\n[ 8687.878427] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0\n[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 8687.905572] PKRU: 55555554\n[ 8687.908286] Call Trace:\n[ 8687.910737]  \u0026lt;TASK\u0026gt;\n[ 8687.912843]  i40e_remove+0x2c0/0x330 [i40e]\n[ 8687.917040]  pci_device_remove+0x33/0xa0\n[ 8687.920962]  device_release_driver_internal+0x1aa/0x230\n[ 8687.926188]  driver_detach+0x44/0x90\n[ 8687.929770]  bus_remove_driver+0x55/0xe0\n[ 8687.933693]  pci_unregister_driver+0x2a/0xb0\n[ 8687.937967]  i40e_exit_module+0xc/0xf48 [i40e]\r\n\r\nTwo offline tests cause IRDMA driver failure (ETIMEDOUT) and this\nfailure is indicated back to i40e_client_subtask() that calls\ni40e_client_del_instance() to free client instance referenced\nby pf-\u0026gt;cinst and sets this pointer to NULL. During the module\nremoval i40e_remove() calls i40e_lan_del_device() that dereferences\npf-\u0026gt;cinst that is NULL -\u0026gt; crash.\nDo not remove client instance when client open callbacks fails and\njust clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs\nto take care about this situation (when netdev is up and client\nis NOT opened) in i40e_notify_client_of_netdev_close() and\ncalls client close callback only when __I40E_CLIENT_INSTANCE_OPENED\nis set.(CVE-2022-48688)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing/osnoise: Do not unregister events twice\r\n\r\nNicolas reported that using:\r\n\r\n # trace-cmd record -e all -M 10 -p osnoise --poll\r\n\r\nResulted in the following kernel warning:\r\n\r\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370\n [...]\n CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19\n RIP: 0010:tracepoint_probe_unregister+0x280/0x370\n [...]\n CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  osnoise_workload_stop+0x36/0x90\n  tracing_set_tracer+0x108/0x260\n  tracing_set_trace_write+0x94/0xd0\n  ? __check_object_size.part.0+0x10a/0x150\n  ? selinux_file_permission+0x104/0x150\n  vfs_write+0xb5/0x290\n  ksys_write+0x5f/0xe0\n  do_syscall_64+0x3b/0x90\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7ff919a18127\n [...]\n ---[ end trace 0000000000000000 ]---\r\n\r\nThe warning complains about an attempt to unregister an\nunregistered tracepoint.\r\n\r\nThis happens on trace-cmd because it first stops tracing, and\nthen switches the tracer to nop. Which is equivalent to:\r\n\r\n  # cd /sys/kernel/tracing/\n  # echo osnoise \u0026gt; current_tracer\n  # echo 0 \u0026gt; tracing_on\n  # echo nop \u0026gt; current_tracer\r\n\r\nThe osnoise tracer stops the workload when no trace instance\nis actually collecting data. This can be caused both by\ndisabling tracing or disabling the tracer itself.\r\n\r\nTo avoid unregistering events twice, use the existing\ntrace_osnoise_callback_enabled variable to check if the events\n(and the workload) are actually active before trying to\ndeactivate them.(CVE-2022-48848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: gadgetfs: Fix race between mounting and unmounting\r\n\r\nThe syzbot fuzzer and Gerald Lee have identified a use-after-free bug\nin the gadgetfs driver, involving processes concurrently mounting and\nunmounting the gadgetfs filesystem.  In particular, gadgetfs_fill_super()\ncan race with gadgetfs_kill_sb(), causing the latter to deallocate\nthe_device while the former is using it.  The output from KASAN says,\nin part:\r\n\r\nBUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]\nBUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]\nBUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]\nBUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]\nBUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]\nBUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]\nBUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086\nWrite of size 4 at addr ffff8880276d7840 by task syz-executor126/18689\r\n\r\nCPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nCall Trace:\n \u0026lt;TASK\u0026gt;\n...\n atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]\n __refcount_sub_and_test include/linux/refcount.h:272 [inline]\n __refcount_dec_and_test include/linux/refcount.h:315 [inline]\n refcount_dec_and_test include/linux/refcount.h:333 [inline]\n put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]\n gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086\n deactivate_locked_super+0xa7/0xf0 fs/super.c:332\n vfs_get_super fs/super.c:1190 [inline]\n get_tree_single+0xd0/0x160 fs/super.c:1207\n vfs_get_tree+0x88/0x270 fs/super.c:1531\n vfs_fsconfig_locked fs/fsopen.c:232 [inline]\r\n\r\nThe simplest solution is to ensure that gadgetfs_fill_super() and\ngadgetfs_kill_sb() are serialized by making them both acquire a new\nmutex.(CVE-2022-48869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi: fix NULL-deref in init error path\r\n\r\nIn cases where runtime services are not supported or have been disabled,\nthe runtime services workqueue will never have been allocated.\r\n\r\nDo not try to destroy the workqueue unconditionally in the unlikely\nevent that EFI initialisation fails to avoid dereferencing a NULL\npointer.(CVE-2022-48879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Cleanup partial engine discovery failures\r\n\r\nIf we abort driver initialisation in the middle of gt/engine discovery,\nsome engines will be fully setup and some not. Those incompletely setup\nengines only have \u0026apos;engine-\u0026gt;release == NULL\u0026apos; and so will leak any of the\ncommon objects allocated.\r\n\r\nv2:\n - Drop the destroy_pinned_context() helper for now.  It\u0026apos;s not really\n   worth it with just a single callsite at the moment.  (Janusz)(CVE-2022-48893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vivid: fix compose size exceed boundary\r\n\r\nsyzkaller found a bug:\r\n\r\n BUG: unable to handle page fault for address: ffffc9000a3b1000\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0\n Oops: 0002 [#1] PREEMPT SMP\n CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n RIP: 0010:memcpy_erms+0x6/0x10\n[...]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? tpg_fill_plane_buffer+0x856/0x15b0\n  vivid_fillbuff+0x8ac/0x1110\n  vivid_thread_vid_cap_tick+0x361/0xc90\n  vivid_thread_vid_cap+0x21a/0x3a0\n  kthread+0x143/0x180\n  ret_from_fork+0x1f/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because we forget to check boundary after adjust compose-\u0026gt;height\nint V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem\nfor this case.(CVE-2022-48945)\r\n\r\nA flaw possibility of memory leak in the Linux kernel cpu_entry_area mapping of X86 CPU data to memory was found in the way user can guess location of exception stack(s) or other important data. A local user could use this flaw to get access to some important data with expected location in memory.(CVE-2023-0597)\r\n\r\nFrom the upstream fix below: The watchdog_timer can schedule tx_timeout_task and watchdog_work can also arm watchdog_timer [..] Although del_timer_sync() and cancel_work_sync() are called in cyttsp4_remove(), the timer and workqueue could still be rearmed. As a result, the possible use after free bugs could happen.\r\n\r\nUpstream commit:\nhttps://github.com/torvalds/linux/commit/dbe836576f12743a7d2d170ad4ad4fd324c4d47a(CVE-2023-4134)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefivarfs: force RO when remounting if SetVariable is not supported\r\n\r\nIf SetVariable at runtime is not supported by the firmware we never assign\na callback for that function. At the same time mount the efivarfs as\nRO so no one can call that.  However, we never check the permission flags\nwhen someone remounts the filesystem as RW. As a result this leads to a\ncrash looking like this:\r\n\r\n$ mount -o remount,rw /sys/firmware/efi/efivars\n$ efi-updatevar -f PK.auth PK\r\n\r\n[  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[  303.280482] Mem abort info:\n[  303.280854]   ESR = 0x0000000086000004\n[  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits\n[  303.282016]   SET = 0, FnV = 0\n[  303.282414]   EA = 0, S1PTW = 0\n[  303.282821]   FSC = 0x04: level 0 translation fault\n[  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000\n[  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP\n[  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6\n[  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1\n[  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023\n[  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  303.292123] pc : 0x0\n[  303.292443] lr : efivar_set_variable_locked+0x74/0xec\n[  303.293156] sp : ffff800008673c10\n[  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000\n[  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027\n[  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000\n[  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000\n[  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54\n[  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4\n[  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002\n[  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201\n[  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc\n[  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000\n[  303.303341] Call trace:\n[  303.303679]  0x0\n[  303.303938]  efivar_entry_set_get_size+0x98/0x16c\n[  303.304585]  efivarfs_file_write+0xd0/0x1a4\n[  303.305148]  vfs_write+0xc4/0x2e4\n[  303.305601]  ksys_write+0x70/0x104\n[  303.306073]  __arm64_sys_write+0x1c/0x28\n[  303.306622]  invoke_syscall+0x48/0x114\n[  303.307156]  el0_svc_common.constprop.0+0x44/0xec\n[  303.307803]  do_el0_svc+0x38/0x98\n[  303.308268]  el0_svc+0x2c/0x84\n[  303.308702]  el0t_64_sync_handler+0xf4/0x120\n[  303.309293]  el0t_64_sync+0x190/0x194\n[  303.309794] Code: ???????? ???????? ???????? ???????? (????????)\n[  303.310612] ---[ end trace 0000000000000000 ]---\r\n\r\nFix this by adding a .reconfigure() function to the fs operations which\nwe can use to check the requested flags and deny anything that\u0026apos;s not RO\nif the firmware doesn\u0026apos;t implement SetVariable at runtime.(CVE-2023-52463)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/psi: Fix use-after-free in ep_remove_wait_queue()\r\n\r\nIf a non-root cgroup gets removed when there is a thread that registered\ntrigger and is polling on a pressure file within the cgroup, the polling\nwaitqueue gets freed in the following path:\r\n\r\n do_rmdir\n   cgroup_rmdir\n     kernfs_drain_open_files\n       cgroup_file_release\n         cgroup_pressure_release\n           psi_trigger_destroy\r\n\r\nHowever, the polling thread still has a reference to the pressure file and\nwill access the freed waitqueue when the file is closed or upon exit:\r\n\r\n fput\n   ep_eventpoll_release\n     ep_free\n       ep_remove_wait_queue\n         remove_wait_queue\r\n\r\nThis results in use-after-free as pasted below.\r\n\r\nThe fundamental problem here is that cgroup_file_release() (and\nconsequently waitqueue\u0026apos;s lifetime) is not tied to the file\u0026apos;s real lifetime.\nUsing wake_up_pollfree() here might be less than ideal, but it is in line\nwith the comment at commit 42288cb44c4b (\u0026quot;wait: add wake_up_pollfree()\u0026quot;)\nsince the waitqueue\u0026apos;s lifetime is not tied to file\u0026apos;s one and can be\nconsidered as another special case. While this would be fixable by somehow\nmaking cgroup_file_release() be tied to the fput(), it would require\nsizable refactoring at cgroups or higher layer which might be more\njustifiable if we identify more cases like this.\r\n\r\n  BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0\n  Write of size 4 at addr ffff88810e625328 by task a.out/4404\r\n\r\n\tCPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38\n\tHardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017\n\tCall Trace:\n\t\u0026lt;TASK\u0026gt;\n\tdump_stack_lvl+0x73/0xa0\n\tprint_report+0x16c/0x4e0\n\tkasan_report+0xc3/0xf0\n\tkasan_check_range+0x2d2/0x310\n\t_raw_spin_lock_irqsave+0x60/0xc0\n\tremove_wait_queue+0x1a/0xa0\n\tep_free+0x12c/0x170\n\tep_eventpoll_release+0x26/0x30\n\t__fput+0x202/0x400\n\ttask_work_run+0x11d/0x170\n\tdo_exit+0x495/0x1130\n\tdo_group_exit+0x100/0x100\n\tget_signal+0xd67/0xde0\n\tarch_do_signal_or_restart+0x2a/0x2b0\n\texit_to_user_mode_prepare+0x94/0x100\n\tsyscall_exit_to_user_mode+0x20/0x40\n\tdo_syscall_64+0x52/0x90\n\tentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\t\u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 4404:\r\n\r\n\tkasan_set_track+0x3d/0x60\n\t__kasan_kmalloc+0x85/0x90\n\tpsi_trigger_create+0x113/0x3e0\n\tpressure_write+0x146/0x2e0\n\tcgroup_file_write+0x11c/0x250\n\tkernfs_fop_write_iter+0x186/0x220\n\tvfs_write+0x3d8/0x5c0\n\tksys_write+0x90/0x110\n\tdo_syscall_64+0x43/0x90\n\tentry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\n Freed by task 4407:\r\n\r\n\tkasan_set_track+0x3d/0x60\n\tkasan_save_free_info+0x27/0x40\n\t____kasan_slab_free+0x11d/0x170\n\tslab_free_freelist_hook+0x87/0x150\n\t__kmem_cache_free+0xcb/0x180\n\tpsi_trigger_destroy+0x2e8/0x310\n\tcgroup_file_release+0x4f/0xb0\n\tkernfs_drain_open_files+0x165/0x1f0\n\tkernfs_drain+0x162/0x1a0\n\t__kernfs_remove+0x1fb/0x310\n\tkernfs_remove_by_name_ns+0x95/0xe0\n\tcgroup_addrm_files+0x67f/0x700\n\tcgroup_destroy_locked+0x283/0x3c0\n\tcgroup_rmdir+0x29/0x100\n\tkernfs_iop_rmdir+0xd1/0x140\n\tvfs_rmdir+0xfe/0x240\n\tdo_rmdir+0x13d/0x280\n\t__x64_sys_rmdir+0x2c/0x30\n\tdo_syscall_64+0x43/0x90\n\tentry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-52707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncifs: Fix use-after-free in rdata-\u0026gt;read_into_pages()\r\n\r\nWhen the network status is unstable, use-after-free may occur when\nread data from the server.\r\n\r\n  BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0\r\n\r\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x38/0x4c\n   print_report+0x16f/0x4a6\n   kasan_report+0xb7/0x130\n   readpages_fill_pages+0x14c/0x7e0\n   cifs_readv_receive+0x46d/0xa40\n   cifs_demultiplex_thread+0x121c/0x1490\n   kthread+0x16b/0x1a0\n   ret_from_fork+0x2c/0x50\n   \u0026lt;/TASK\u0026gt;\r\n\r\n  Allocated by task 2535:\n   kasan_save_stack+0x22/0x50\n   kasan_set_track+0x25/0x30\n   __kasan_kmalloc+0x82/0x90\n   cifs_readdata_direct_alloc+0x2c/0x110\n   cifs_readdata_alloc+0x2d/0x60\n   cifs_readahead+0x393/0xfe0\n   read_pages+0x12f/0x470\n   page_cache_ra_unbounded+0x1b1/0x240\n   filemap_get_pages+0x1c8/0x9a0\n   filemap_read+0x1c0/0x540\n   cifs_strict_readv+0x21b/0x240\n   vfs_read+0x395/0x4b0\n   ksys_read+0xb8/0x150\n   do_syscall_64+0x3f/0x90\n   entry_SYSCALL_64_after_hwframe+0x72/0xdc\r\n\r\n  Freed by task 79:\n   kasan_save_stack+0x22/0x50\n   kasan_set_track+0x25/0x30\n   kasan_save_free_info+0x2e/0x50\n   __kasan_slab_free+0x10e/0x1a0\n   __kmem_cache_free+0x7a/0x1a0\n   cifs_readdata_release+0x49/0x60\n   process_one_work+0x46c/0x760\n   worker_thread+0x2a4/0x6f0\n   kthread+0x16b/0x1a0\n   ret_from_fork+0x2c/0x50\r\n\r\n  Last potentially related work creation:\n   kasan_save_stack+0x22/0x50\n   __kasan_record_aux_stack+0x95/0xb0\n   insert_work+0x2b/0x130\n   __queue_work+0x1fe/0x660\n   queue_work_on+0x4b/0x60\n   smb2_readv_callback+0x396/0x800\n   cifs_abort_connection+0x474/0x6a0\n   cifs_reconnect+0x5cb/0xa50\n   cifs_readv_from_socket.cold+0x22/0x6c\n   cifs_read_page_from_socket+0xc1/0x100\n   readpages_fill_pages.cold+0x2f/0x46\n   cifs_readv_receive+0x46d/0xa40\n   cifs_demultiplex_thread+0x121c/0x1490\n   kthread+0x16b/0x1a0\n   ret_from_fork+0x2c/0x50\r\n\r\nThe following function calls will cause UAF of the rdata pointer.\r\n\r\nreadpages_fill_pages\n cifs_read_page_from_socket\n  cifs_readv_from_socket\n   cifs_reconnect\n    __cifs_reconnect\n     cifs_abort_connection\n      mid-\u0026gt;callback() --\u0026gt; smb2_readv_callback\n       queue_work(\u0026amp;rdata-\u0026gt;work)  # if the worker completes first,\n                                 # the rdata is freed\n          cifs_readv_complete\n            kref_put\n              cifs_readdata_release\n                kfree(rdata)\n return rdata-\u0026gt;...               # UAF in readpages_fill_pages()\r\n\r\nSimilarly, this problem also occurs in the uncache_fill_pages().\r\n\r\nFix this by adjusts the order of condition judgment in the return\nstatement.(CVE-2023-52741)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\r\n\r\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\r\n\r\nRequire initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkeys: Fix overwrite of key expiration on instantiation\r\n\r\nThe expiry time of a key is unconditionally overwritten during\ninstantiation, defaulting to turn it permanent. This causes a problem\nfor DNS resolution as the expiration set by user-space is overwritten to\nTIME64_MAX, disabling further DNS updates. Fix this by restoring the\ncondition that key_set_expiry is only called when the pre-parser sets a\nspecific expiry.(CVE-2024-36031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix uninitialized ratelimit_state-\u0026gt;lock access in __ext4_fill_super()\r\n\r\nIn the following concurrency we will access the uninitialized rs-\u0026gt;lock:\r\n\r\next4_fill_super\n  ext4_register_sysfs\n   // sysfs registered msg_ratelimit_interval_ms\n                             // Other processes modify rs-\u0026gt;interval to\n                             // non-zero via msg_ratelimit_interval_ms\n  ext4_orphan_cleanup\n    ext4_msg(sb, KERN_INFO, \u0026quot;Errors on filesystem, \u0026quot;\n      __ext4_msg\n        ___ratelimit(\u0026amp;(EXT4_SB(sb)-\u0026gt;s_msg_ratelimit_state)\n          if (!rs-\u0026gt;interval)  // do nothing if interval is 0\n            return 1;\n          raw_spin_trylock_irqsave(\u0026amp;rs-\u0026gt;lock, flags)\n            raw_spin_trylock(lock)\n              _raw_spin_trylock\n                __raw_spin_trylock\n                  spin_acquire(\u0026amp;lock-\u0026gt;dep_map, 0, 1, _RET_IP_)\n                    lock_acquire\n                      __lock_acquire\n                        register_lock_class\n                          assign_lock_key\n                            dump_stack();\n  ratelimit_state_init(\u0026amp;sbi-\u0026gt;s_msg_ratelimit_state, 5 * HZ, 10);\n    raw_spin_lock_init(\u0026amp;rs-\u0026gt;lock);\n    // init rs-\u0026gt;lock here\r\n\r\nand get the following dump_stack:\r\n\r\n=========================================================\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0026apos;t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504\n[...]\nCall Trace:\n dump_stack_lvl+0xc5/0x170\n dump_stack+0x18/0x30\n register_lock_class+0x740/0x7c0\n __lock_acquire+0x69/0x13a0\n lock_acquire+0x120/0x450\n _raw_spin_trylock+0x98/0xd0\n ___ratelimit+0xf6/0x220\n __ext4_msg+0x7f/0x160 [ext4]\n ext4_orphan_cleanup+0x665/0x740 [ext4]\n __ext4_fill_super+0x21ea/0x2b10 [ext4]\n ext4_fill_super+0x14d/0x360 [ext4]\n[...]\n=========================================================\r\n\r\nNormally interval is 0 until s_msg_ratelimit_state is initialized, so\n___ratelimit() does nothing. But registering sysfs precedes initializing\nrs-\u0026gt;lock, so it is possible to change rs-\u0026gt;interval to a non-zero value\nvia the msg_ratelimit_interval_ms interface of sysfs while rs-\u0026gt;lock is\nuninitialized, and then a call to ext4_msg triggers the problem by\naccessing an uninitialized rs-\u0026gt;lock. Therefore register sysfs after all\ninitializations are complete to avoid such problems.(CVE-2024-40998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\r\n\r\nset_memory_rox() can fail, leaving memory unprotected.\r\n\r\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.(CVE-2024-42067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nexthop: Initialize all fields in dumped nexthops\r\n\r\nstruct nexthop_grp contains two reserved fields that are not initialized by\nnla_put_nh_group(), and carry garbage. This can be observed e.g. with\nstrace (edited for clarity):\r\n\r\n    # ip nexthop add id 1 dev lo\n    # ip nexthop add id 101 group 1\n    # strace -e recvmsg ip nexthop get id 101\n    ...\n    recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},\n                 [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52\r\n\r\nThe fields are reserved and therefore not currently used. But as they are, they\nleak kernel memory, and the fact they are not just zero complicates repurposing\nof the fields for new ends. Initialize the full structure.(CVE-2024-42283)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nirqchip/imx-irqsteer: Handle runtime power management correctly\r\n\r\nThe power domain is automatically activated from clk_prepare(). However, on\ncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes\nsleeping functions, which triggers the \u0026apos;scheduling while atomic\u0026apos; bug in the\ncontext switch path during device probing:\r\n\r\n BUG: scheduling while atomic: kworker/u13:1/48/0x00000002\n Call trace:\n  __schedule_bug+0x54/0x6c\n  __schedule+0x7f0/0xa94\n  schedule+0x5c/0xc4\n  schedule_preempt_disabled+0x24/0x40\n  __mutex_lock.constprop.0+0x2c0/0x540\n  __mutex_lock_slowpath+0x14/0x20\n  mutex_lock+0x48/0x54\n  clk_prepare_lock+0x44/0xa0\n  clk_prepare+0x20/0x44\n  imx_irqsteer_resume+0x28/0xe0\n  pm_generic_runtime_resume+0x2c/0x44\n  __genpd_runtime_resume+0x30/0x80\n  genpd_runtime_resume+0xc8/0x2c0\n  __rpm_callback+0x48/0x1d8\n  rpm_callback+0x6c/0x78\n  rpm_resume+0x490/0x6b4\n  __pm_runtime_resume+0x50/0x94\n  irq_chip_pm_get+0x2c/0xa0\n  __irq_do_set_handler+0x178/0x24c\n  irq_set_chained_handler_and_data+0x60/0xa4\n  mxc_gpio_probe+0x160/0x4b0\r\n\r\nCure this by implementing the irq_bus_lock/sync_unlock() interrupt chip\ncallbacks and handle power management in them as they are invoked from\nnon-atomic context.\r\n\r\n[ tglx: Rewrote change log, added Fixes tag ](CVE-2024-42290)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes\r\n\r\nIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42309)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: venus: fix use after free in vdec_close\r\n\r\nThere appears to be a possible use after free with vdec_close().\nThe firmware will add buffer release work to the work queue through\nHFI callbacks as a normal part of decoding. Randomly closing the\ndecoder device from userspace during normal decoding can incur\na read after free for inst.\r\n\r\nFix it by cancelling the work in vdec_close.(CVE-2024-42313)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvs: properly dereference pe in ip_vs_add_service\r\n\r\nUse pe directly to resolve sparse warning:\r\n\r\n  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()\r\n\r\nIf IORESOURCE_MEM is not provided in Device Tree due to\nany error, resource_list_first_type() will return NULL and\npci_parse_request_of_pci_ranges() will just emit a warning.\r\n\r\nThis will cause a NULL pointer dereference. Fix this bug by adding NULL\nreturn check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: trigger: Unregister sysfs attributes before calling deactivate()\r\n\r\nTriggers which have trigger specific sysfs attributes typically store\nrelated data in trigger-data allocated by the activate() callback and\nfreed by the deactivate() callback.\r\n\r\nCalling device_remove_groups() after calling deactivate() leaves a window\nwhere the sysfs attributes show/store functions could be called after\ndeactivation and then operate on the just freed trigger-data.\r\n\r\nMove the device_remove_groups() call to before deactivate() to close\nthis race window.\r\n\r\nThis also makes the deactivation path properly do things in reverse order\nof the activation path which calls the activate() callback before calling\ndevice_add_groups().(CVE-2024-43830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix deadlock between mddev_suspend and flush bio\r\n\r\nDeadlock occurs when mddev is being suspended while some flush bio is in\nprogress. It is a complex issue.\r\n\r\nT1. the first flush is at the ending stage, it clears \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;\n    and tries to submit data, but is blocked because mddev is suspended\n    by T4.\nT2. the second flush sets \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;, and attempts to queue\n    md_submit_flush_data(), which is already running (T1) and won\u0026apos;t\n    execute again if on the same CPU as T1.\nT3. the third flush inc active_io and tries to flush, but is blocked because\n    \u0026apos;mddev-\u0026gt;flush_bio\u0026apos; is not NULL (set by T2).\nT4. mddev_suspend() is called and waits for active_io dec to 0 which is inc\n    by T3.\r\n\r\n  T1\t\tT2\t\tT3\t\tT4\n  (flush 1)\t(flush 2)\t(third 3)\t(suspend)\n  md_submit_flush_data\n   mddev-\u0026gt;flush_bio = NULL;\n   .\n   .\t \tmd_flush_request\n   .\t  \t mddev-\u0026gt;flush_bio = bio\n   .\t  \t queue submit_flushes\n   .\t\t .\n   .\t\t .\t\tmd_handle_request\n   .\t\t .\t\t active_io + 1\n   .\t\t .\t\t md_flush_request\n   .\t\t .\t\t  wait !mddev-\u0026gt;flush_bio\n   .\t\t .\n   .\t\t .\t\t\t\tmddev_suspend\n   .\t\t .\t\t\t\t wait !active_io\n   .\t\t .\n   .\t\t submit_flushes\n   .\t\t queue_work md_submit_flush_data\n   .\t\t //md_submit_flush_data is already running (T1)\n   .\n   md_handle_request\n    wait resume\r\n\r\nThe root issue is non-atomic inc/dec of active_io during flush process.\nactive_io is dec before md_submit_flush_data is queued, and inc soon\nafter md_submit_flush_data() run.\n  md_flush_request\n    active_io + 1\n    submit_flushes\n      active_io - 1\n      md_submit_flush_data\n        md_handle_request\n        active_io + 1\n          make_request\n        active_io - 1\r\n\r\nIf active_io is dec after md_handle_request() instead of within\nsubmit_flushes(), make_request() can be called directly intead of\nmd_handle_request() in md_submit_flush_data(), and active_io will\nonly inc and dec once in the whole flush process. Deadlock will be\nfixed.\r\n\r\nAdditionally, the only difference between fixing the issue and before is\nthat there is no return error handling of make_request(). But after\nprevious patch cleaned md_write_start(), make_requst() only return error\nin raid5_make_request() by dm-raid, see commit 41425f96d7aa (\u0026quot;dm-raid456,\nmd/raid456: fix a deadlock for dm-raid456 while io concurrent with\nreshape)\u0026quot;. Since dm always splits data and flush operation into two\nseparate io, io size of flush submitted by dm always is 0, make_request()\nwill not be called in md_submit_flush_data(). To prevent future\nmodifications from introducing issues, add WARN_ON to ensure\nmake_request() no error is returned in this context.(CVE-2024-43855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg: protect concurrent access to mem_cgroup_idr\r\n\r\nCommit 73f576c04b94 (\u0026quot;mm: memcontrol: fix cgroup creation failure after\nmany small jobs\u0026quot;) decoupled the memcg IDs from the CSS ID space to fix the\ncgroup creation failures.  It introduced IDR to maintain the memcg ID\nspace.  The IDR depends on external synchronization mechanisms for\nmodifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()\nhappen within css callback and thus are protected through cgroup_mutex\nfrom concurrent modifications.  However idr_remove() for mem_cgroup_idr\nwas not protected against concurrency and can be run concurrently for\ndifferent memcgs when they hit their refcnt to zero.  Fix that.\r\n\r\nWe have been seeing list_lru based kernel crashes at a low frequency in\nour fleet for a long time.  These crashes were in different part of\nlist_lru code including list_lru_add(), list_lru_del() and reparenting\ncode.  Upon further inspection, it looked like for a given object (dentry\nand inode), the super_block\u0026apos;s list_lru didn\u0026apos;t have list_lru_one for the\nmemcg of that object.  The initial suspicions were either the object is\nnot allocated through kmem_cache_alloc_lru() or somehow\nmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but\nreturned success.  No evidence were found for these cases.\r\n\r\nLooking more deeply, we started seeing situations where valid memcg\u0026apos;s id\nis not present in mem_cgroup_idr and in some cases multiple valid memcgs\nhave same id and mem_cgroup_idr is pointing to one of them.  So, the most\nreasonable explanation is that these situations can happen due to race\nbetween multiple idr_remove() calls or race between\nidr_alloc()/idr_replace() and idr_remove().  These races are causing\nmultiple memcgs to acquire the same ID and then offlining of one of them\nwould cleanup list_lrus on the system for all of them.  Later access from\nother memcgs to the list_lru cause crashes due to missing list_lru_one.(CVE-2024-43892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: core: check uartclk for zero to avoid divide by zero\r\n\r\nCalling ioctl TIOCSSERIAL with an invalid baud_base can\nresult in uartclk being zero, which will result in a\ndivide by zero error in uart_get_divisor(). The check for\nuartclk being zero in uart_set_info() needs to be done\nbefore other settings are made as subsequent calls to\nioctl TIOCSSERIAL for the same port would be impacted if\nthe uartclk check was done where uartclk gets set.\r\n\r\nOops: divide error: 0000  PREEMPT SMP KASAN PTI\nRIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)\nCall Trace:\n \u0026lt;TASK\u0026gt;\nserial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576\n    drivers/tty/serial/8250/8250_port.c:2589)\nserial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502\n    drivers/tty/serial/8250/8250_port.c:2741)\nserial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)\nuart_change_line_settings (./include/linux/spinlock.h:376\n    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)\nuart_port_startup (drivers/tty/serial/serial_core.c:342)\nuart_startup (drivers/tty/serial/serial_core.c:368)\nuart_set_info (drivers/tty/serial/serial_core.c:1034)\nuart_set_info_user (drivers/tty/serial/serial_core.c:1059)\ntty_set_serial (drivers/tty/tty_io.c:2637)\ntty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)\n__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907\n    fs/ioctl.c:893 fs/ioctl.c:893)\ndo_syscall_64 (arch/x86/entry/common.c:52\n    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nRule: add(CVE-2024-43893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfou: remove warn in gue_gro_receive on unsupported protocol\r\n\r\nDrop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is\nnot known or does not have a GRO handler.\r\n\r\nSuch a packet is easily constructed. Syzbot generates them and sets\noff this warning.\r\n\r\nRemove the warning as it is expected and not actionable.\r\n\r\nThe warning was previously reduced from WARN_ON to WARN_ON_ONCE in\ncommit 270136613bf7 (\u0026quot;fou: Do WARN_ON_ONCE in gue_gro_receive for bad\nproto callbacks\u0026quot;).(CVE-2024-44940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natm: idt77252: prevent use after free in dequeue_rx()\r\n\r\nWe can\u0026apos;t dereference \u0026quot;skb\u0026quot; after calling vcc-\u0026gt;push() because the skb\nis released.(CVE-2024-44998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix Panther point NULL pointer deref at full-speed re-enumeration\r\n\r\nre-enumerating full-speed devices after a failed address device command\ncan trigger a NULL pointer dereference.\r\n\r\nFull-speed devices may need to reconfigure the endpoint 0 Max Packet Size\nvalue during enumeration. Usb core calls usb_ep0_reinit() in this case,\nwhich ends up calling xhci_configure_endpoint().\r\n\r\nOn Panther point xHC the xhci_configure_endpoint() function will\nadditionally check and reserve bandwidth in software. Other hosts do\nthis in hardware\r\n\r\nIf xHC address device command fails then a new xhci_virt_device structure\nis allocated as part of re-enabling the slot, but the bandwidth table\npointers are not set up properly here.\nThis triggers the NULL pointer dereference the next time usb_ep0_reinit()\nis called and xhci_configure_endpoint() tries to check and reserve\nbandwidth\r\n\r\n[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd\n[46710.713699] usb 3-1: Device not responding to setup address.\n[46710.917684] usb 3-1: Device not responding to setup address.\n[46711.125536] usb 3-1: device not accepting address 5, error -71\n[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[46711.125600] #PF: supervisor read access in kernel mode\n[46711.125603] #PF: error_code(0x0000) - not-present page\n[46711.125606] PGD 0 P4D 0\n[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI\n[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1\n[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.\n[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]\n[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c\r\n\r\nFix this by making sure bandwidth table pointers are set up correctly\nafter a failed address device command, and additionally by avoiding\nchecking for bandwidth in cases like this where no actual endpoints are\nadded or removed, i.e. only context for default control endpoint 0 is\nevaluated.(CVE-2024-45006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix error recovery leading to data corruption on ESE devices\r\n\r\nExtent Space Efficient (ESE) or thin provisioned volumes need to be\nformatted on demand during usual IO processing.\r\n\r\nThe dasd_ese_needs_format function checks for error codes that signal\nthe non existence of a proper track format.\r\n\r\nThe check for incorrect length is to imprecise since other error cases\nleading to transport of insufficient data also have this flag set.\nThis might lead to data corruption in certain error cases for example\nduring a storage server warmstart.\r\n\r\nFix by removing the check for incorrect length and replacing by\nexplicitly checking for invalid track format in transport mode.\r\n\r\nAlso remove the check for file protected since this is not a valid\nESE handling case.(CVE-2024-45026)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: pn533: Add poll mod list filling check\r\n\r\nIn case of im_protocols value is 1 and tm_protocols value is 0 this\ncombination successfully passes the check\n\u0026apos;if (!im_protocols \u0026amp;\u0026amp; !tm_protocols)\u0026apos; in the nfc_start_poll().\nBut then after pn533_poll_create_mod_list() call in pn533_start_poll()\npoll mod list will remain empty and dev-\u0026gt;poll_mod_count will remain 0\nwhich lead to division by zero.\r\n\r\nNormally no im protocol has value 1 in the mask, so this combination is\nnot expected by driver. But these protocol values actually come from\nuserspace via Netlink interface (NFC_CMD_START_POLL operation). So a\nbroken or malicious program may pass a message containing a \u0026quot;bad\u0026quot;\ncombination of protocol parameter values so that dev-\u0026gt;poll_mod_count\nis not incremented inside pn533_poll_create_mod_list(), thus leading\nto division by zero.\nCall trace looks like:\nnfc_genl_start_poll()\n  nfc_start_poll()\n    -\u0026gt;start_poll()\n    pn533_start_poll()\r\n\r\nAdd poll mod list filling check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: ucsi: Fix null pointer dereference in trace\r\n\r\nucsi_register_altmode checks IS_ERR for the alt pointer and treats\nNULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,\nucsi_register_displayport returns NULL which causes a NULL pointer\ndereference in trace. Rather than return NULL, call\ntypec_port_register_altmode to register DisplayPort alternate mode\nas a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Remove tst_run from lwt_seg6local_prog_ops.\r\n\r\nThe syzbot reported that the lwt_seg6 related BPF ops can be invoked\nvia bpf_test_run() without without entering input_action_end_bpf()\nfirst.\r\n\r\nMartin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL\nprobably didn\u0026apos;t work since it was introduced in commit 04d4b274e2a\n(\u0026quot;ipv6: sr: Add seg6local action End.BPF\u0026quot;). The reason is that the\nper-CPU variable seg6_bpf_srh_states::srh is never assigned in the self\ntest case but each BPF function expects it.\r\n\r\nRemove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.(CVE-2024-46754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Add netif_device_attach/detach into PF reset flow\r\n\r\nEthtool callbacks can be executed while reset is in progress and try to\naccess deleted resources, e.g. getting coalesce settings can result in a\nNULL pointer dereference seen below.\r\n\r\nReproduction steps:\nOnce the driver is fully initialized, trigger reset:\n\t# echo 1 \u0026gt; /sys/class/net/\u0026lt;interface\u0026gt;/device/reset\nwhen reset is in progress try to get coalesce settings using ethtool:\n\t# ethtool -c \u0026lt;interface\u0026gt;\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000020\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP PTI\nCPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7\nRIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]\nRSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206\nRAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000\nR13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40\nFS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0\nCall Trace:\n\u0026lt;TASK\u0026gt;\nice_get_coalesce+0x17/0x30 [ice]\ncoalesce_prepare_data+0x61/0x80\nethnl_default_doit+0xde/0x340\ngenl_family_rcv_msg_doit+0xf2/0x150\ngenl_rcv_msg+0x1b3/0x2c0\nnetlink_rcv_skb+0x5b/0x110\ngenl_rcv+0x28/0x40\nnetlink_unicast+0x19c/0x290\nnetlink_sendmsg+0x222/0x490\n__sys_sendto+0x1df/0x1f0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x82/0x160\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7faee60d8e27\r\n\r\nCalling netif_device_detach() before reset makes the net core not call\nthe driver when ethtool command is issued, the attempt to execute an\nethtool command during reset will result in the following message:\r\n\r\n    netlink error: No such device\r\n\r\ninstead of NULL pointer dereference. Once reset is done and\nice_rebuild() is executing, the netif_device_attach() is called to allow\nfor ethtool operations to occur again in a safe manner.(CVE-2024-46770)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: unset the binding mark of a reused connection\r\n\r\nSteve French reported null pointer dereference error from sha256 lib.\ncifs.ko can send session setup requests on reused connection.\nIf reused connection is used for binding session, conn-\u0026gt;binding can\nstill remain true and generate_preauth_hash() will not set\nsess-\u0026gt;Preauth_HashValue and it will be NULL.\nIt is used as a material to create an encryption key in\nksmbd_gen_smb311_encryptionkey. -\u0026gt;Preauth_HashValue cause null pointer\ndereference error from crypto_shash_update().\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 8 PID: 429254 Comm: kworker/8:39\nHardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )\nWorkqueue: ksmbd-io handle_ksmbd_work [ksmbd]\nRIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n\u0026lt;TASK\u0026gt;\n? show_regs+0x6d/0x80\n? __die+0x24/0x80\n? page_fault_oops+0x99/0x1b0\n? do_user_addr_fault+0x2ee/0x6b0\n? exc_page_fault+0x83/0x1b0\n? asm_exc_page_fault+0x27/0x30\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n_sha256_update+0x77/0xa0 [sha256_ssse3]\nsha256_avx2_update+0x15/0x30 [sha256_ssse3]\ncrypto_shash_update+0x1e/0x40\nhmac_update+0x12/0x20\ncrypto_shash_update+0x1e/0x40\ngenerate_key+0x234/0x380 [ksmbd]\ngenerate_smb3encryptionkey+0x40/0x1c0 [ksmbd]\nksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]\nntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]\nsmb2_sess_setup+0x952/0xaa0 [ksmbd]\n__process_request+0xa3/0x1d0 [ksmbd]\n__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]\nhandle_ksmbd_work+0x2d/0xa0 [ksmbd]\nprocess_one_work+0x16c/0x350\nworker_thread+0x306/0x440\n? __pfx_worker_thread+0x10/0x10\nkthread+0xef/0x120\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x44/0x70\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1b/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2024-46795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: the warning dereferencing obj for nbio_v7_4\r\n\r\nif ras_manager obj null, don\u0026apos;t print NBIO err data(CVE-2024-46819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched: sch_cake: fix bulk flow accounting logic for host fairness\r\n\r\nIn sch_cake, we keep track of the count of active bulk flows per host,\nwhen running in dst/src host fairness mode, which is used as the\nround-robin weight when iterating through flows. The count of active\nbulk flows is updated whenever a flow changes state.\r\n\r\nThis has a peculiar interaction with the hash collision handling: when a\nhash collision occurs (after the set-associative hashing), the state of\nthe hash bucket is simply updated to match the new packet that collided,\nand if host fairness is enabled, that also means assigning new per-host\nstate to the flow. For this reason, the bulk flow counters of the\nhost(s) assigned to the flow are decremented, before new state is\nassigned (and the counters, which may not belong to the same host\nanymore, are incremented again).\r\n\r\nBack when this code was introduced, the host fairness mode was always\nenabled, so the decrement was unconditional. When the configuration\nflags were introduced the *increment* was made conditional, but\nthe *decrement* was not. Which of course can lead to a spurious\ndecrement (and associated wrap-around to U16_MAX).\r\n\r\nAFAICT, when host fairness is disabled, the decrement and wrap-around\nhappens as soon as a hash collision occurs (which is not that common in\nitself, due to the set-associative hashing). However, in most cases this\nis harmless, as the value is only used when host fairness mode is\nenabled. So in order to trigger an array overflow, sch_cake has to first\nbe configured with host fairness disabled, and while running in this\nmode, a hash collision has to occur to cause the overflow. Then, the\nqdisc has to be reconfigured to enable host fairness, which leads to the\narray out-of-bounds because the wrapped-around value is retained and\nused as an array index. It seems that syzbot managed to trigger this,\nwhich is quite impressive in its own right.\r\n\r\nThis patch fixes the issue by introducing the same conditional check on\ndecrement as is used on increment.\r\n\r\nThe original bug predates the upstreaming of cake, but the commit listed\nin the Fixes tag touched that code, meaning that this patch won\u0026apos;t apply\nbefore that.(CVE-2024-46828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: clean up our handling of refs == 0 in snapshot delete\r\n\r\nIn reada we BUG_ON(refs == 0), which could be unkind since we aren\u0026apos;t\nholding a lock on the extent leaf and thus could get a transient\nincorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which\ncould happen if we have extent tree corruption.  Change that to return\n-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,\nhowever we return -EIO, which -EUCLEAN is a more appropriate error code.\nFinally in walk_up_proc we have the same BUG_ON(refs == 0), so convert\nthat to proper error handling.  Also adjust the error message so we can\nactually do something with the information.(CVE-2024-46840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/x86/intel: Limit the period on Haswell\r\n\r\nRunning the ltp test cve-2015-3290 concurrently reports the following\nwarnings.\r\n\r\nperfevents: irq loop stuck!\n  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174\n  intel_pmu_handle_irq+0x285/0x370\n  Call Trace:\n   \u0026lt;NMI\u0026gt;\n   ? __warn+0xa4/0x220\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? __report_bug+0x123/0x130\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? __report_bug+0x123/0x130\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? report_bug+0x3e/0xa0\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x50\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? irq_work_claim+0x1e/0x40\n   ? intel_pmu_handle_irq+0x285/0x370\n   perf_event_nmi_handler+0x3d/0x60\n   nmi_handle+0x104/0x330\r\n\r\nThanks to Thomas Gleixner\u0026apos;s analysis, the issue is caused by the low\ninitial period (1) of the frequency estimation algorithm, which triggers\nthe defects of the HW, specifically erratum HSW11 and HSW143. (For the\ndetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)\r\n\r\nThe HSW11 requires a period larger than 100 for the INST_RETIRED.ALL\nevent, but the initial period in the freq mode is 1. The erratum is the\nsame as the BDM11, which has been supported in the kernel. A minimum\nperiod of 128 is enforced as well on HSW.\r\n\r\nHSW143 is regarding that the fixed counter 1 may overcount 32 with the\nHyper-Threading is enabled. However, based on the test, the hardware\nhas more issues than it tells. Besides the fixed counter 1, the message\n\u0026apos;interrupt took too long\u0026apos; can be observed on any counter which was armed\nwith a period \u0026lt; 32 and two events expired in the same NMI. A minimum\nperiod of 32 is enforced for the rest of the events.\nThe recommended workaround code of the HSW143 is not implemented.\nBecause it only addresses the issue for the fixed counter. It brings\nextra overhead through extra MSR writing. No related overcounting issue\nhas been reported so far.(CVE-2024-46848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dpaa: Pad packets to ETH_ZLEN\r\n\r\nWhen sending packets under 60 bytes, up to three bytes of the buffer\nfollowing the data may be leaked. Avoid this by extending all packets to\nETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be\nreproduced by running\r\n\r\n\t$ ping -s 11 destination(CVE-2024-46854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_socket: fix sk refcount leaks\r\n\r\nWe must put \u0026apos;sk\u0026apos; reference before returning.(CVE-2024-46855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: Fix uaf in __timer_delete_sync\r\n\r\nThere are two paths to access mptcp_pm_del_add_timer, result in a race\ncondition:\r\n\r\n     CPU1\t\t\t\tCPU2\n     ====                               ====\n     net_rx_action\n     napi_poll                          netlink_sendmsg\n     __napi_poll                        netlink_unicast\n     process_backlog                    netlink_unicast_kernel\n     __netif_receive_skb                genl_rcv\n     __netif_receive_skb_one_core       netlink_rcv_skb\n     NF_HOOK                            genl_rcv_msg\n     ip_local_deliver_finish            genl_family_rcv_msg\n     ip_protocol_deliver_rcu            genl_family_rcv_msg_doit\n     tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit\n     tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list\n     tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows\n     tcp_data_queue                     remove_anno_list_by_saddr\n     mptcp_incoming_options             mptcp_pm_del_add_timer\n     mptcp_pm_del_add_timer             kfree(entry)\r\n\r\nIn remove_anno_list_by_saddr(running on CPU2), after leaving the critical\nzone protected by \u0026quot;pm.lock\u0026quot;, the entry will be released, which leads to the\noccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).\r\n\r\nKeeping a reference to add_timer inside the lock, and calling\nsk_stop_timer_sync() with this reference, instead of \u0026quot;entry-\u0026gt;add_timer\u0026quot;.\r\n\r\nMove list_del(\u0026amp;entry-\u0026gt;list) to mptcp_pm_del_add_timer and inside the pm lock,\ndo not directly access any members of the entry outside the pm lock, which\ncan avoid similar \u0026quot;entry-\u0026gt;x\u0026quot; uaf.(CVE-2024-46858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: stm32/cryp - call finalize with bh disabled\r\n\r\nThe finalize operation in interrupt mode produce a produces a spinlock\nrecursion warning. The reason is the fact that BH must be disabled\nduring this process.(CVE-2024-47658)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware\r\n\r\nIf the value of max_speed_hz is 0, it may cause a division by zero\nerror in hisi_calc_effective_speed().\nThe value of max_speed_hz is provided by firmware.\nFirmware is generally considered as a trusted domain. However, as\ndivision by zero errors can cause system failure, for defense measure,\nthe value of max_speed is validated here. So 0 is regarded as invalid\nand an error code is returned.(CVE-2024-47664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_xattr_find_entry()\r\n\r\nAdd a paranoia check to make sure it doesn\u0026apos;t stray beyond valid memory\nregion containing ocfs2 xattr entries when scanning for a match.  It will\nprevent out-of-bound access in case of crafted images.(CVE-2024-47670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usbtmc: prevent kernel-usb-infoleak\r\n\r\nThe syzbot reported a kernel-usb-infoleak in usbtmc_write,\nwe need to clear the structure before filling fields.(CVE-2024-47671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: don\u0026apos;t wait for tx queues if firmware is dead\r\n\r\nThere is a WARNING in iwl_trans_wait_tx_queues_empty() (that was\nrecently converted from just a message), that can be hit if we\nwait for TX queues to become empty after firmware died. Clearly,\nwe can\u0026apos;t expect anything from the firmware after it\u0026apos;s declared dead.\r\n\r\nDon\u0026apos;t call iwl_trans_wait_tx_queues_empty() in this case. While it could\nbe a good idea to stop the flow earlier, the flush functions do some\nmaintenance work that is not related to the firmware, so keep that part\nof the code running even when the firmware is not running.\r\n\r\n[edit commit message](CVE-2024-47672)","status":"published","published":"2024-10-18T11:07:44Z","modified":"2026-08-18T01:17:35.636859842Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2024-2258","title":"kernel security update","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\ns390/qeth: fix deadlock during failing recovery\r\n\r\nCommit 0b9902c1fcc5 (\u0026quot;s390/qeth: fix deadlock during recovery\u0026quot;) removed\ntaking discipline_mutex inside qeth_do_reset(), fixing potential\ndeadlocks. An error path was missed though, that still takes\ndiscipline_mutex and thus has the original deadlock potential.\r\n\r\nIntermittent deadlocks were seen when a qeth channel path is configured\noffline, causing a race between qeth_do_reset and ccwgroup_remove.\nCall qeth_set_offline() directly in the qeth_do_reset() error case and\nthen a new variant of ccwgroup_set_offline(), without taking\ndiscipline_mutex.(CVE-2021-47382)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Cleanup partial engine discovery failures\r\n\r\nIf we abort driver initialisation in the middle of gt/engine discovery,\nsome engines will be fully setup and some not. Those incompletely setup\nengines only have \u0026apos;engine-\u0026gt;release == NULL\u0026apos; and so will leak any of the\ncommon objects allocated.\r\n\r\nv2:\n - Drop the destroy_pinned_context() helper for now.  It\u0026apos;s not really\n   worth it with just a single callsite at the moment.  (Janusz)(CVE-2022-48893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: ncm: Fix handling of zero block length packets\r\n\r\nWhile connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX\nset to 65536, it has been observed that we receive short packets,\nwhich come at interval of 5-10 seconds sometimes and have block\nlength zero but still contain 1-2 valid datagrams present.\r\n\r\nAccording to the NCM spec:\r\n\r\n\u0026quot;If wBlockLength = 0x0000, the block is terminated by a\nshort packet. In this case, the USB transfer must still\nbe shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If\nexactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,\nand the size is a multiple of wMaxPacketSize for the\ngiven pipe, then no ZLP shall be sent.\r\n\r\nwBlockLength= 0x0000 must be used with extreme care, because\nof the possibility that the host and device may get out of\nsync, and because of test issues.\r\n\r\nwBlockLength = 0x0000 allows the sender to reduce latency by\nstarting to send a very large NTB, and then shortening it when\nthe sender discovers that there’s not sufficient data to justify\nsending a large NTB\u0026quot;\r\n\r\nHowever, there is a potential issue with the current implementation,\nas it checks for the occurrence of multiple NTBs in a single\ngiveback by verifying if the leftover bytes to be processed is zero\nor not. If the block length reads zero, we would process the same\nNTB infintely because the leftover bytes is never zero and it leads\nto a crash. Fix this by bailing out if block length reads zero.(CVE-2024-35825)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr\r\n\r\nAlthough ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it\nstill means hlist_for_each_entry_rcu can return an item that got removed\nfrom the list. The memory itself of such item is not freed thanks to RCU\nbut nothing guarantees the actual content of the memory is sane.\r\n\r\nIn particular, the reference count can be zero. This can happen if\nipv6_del_addr is called in parallel. ipv6_del_addr removes the entry\nfrom inet6_addr_lst (hlist_del_init_rcu(\u0026amp;ifp-\u0026gt;addr_lst)) and drops all\nreferences (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough\ntiming, this can happen:\r\n\r\n1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.\r\n\r\n2. Then, the whole ipv6_del_addr is executed for the given entry. The\n   reference count drops to zero and kfree_rcu is scheduled.\r\n\r\n3. ipv6_get_ifaddr continues and tries to increments the reference count\n   (in6_ifa_hold).\r\n\r\n4. The rcu is unlocked and the entry is freed.\r\n\r\n5. The freed entry is returned.\r\n\r\nPrevent increasing of the reference count in such case. The name\nin6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.\r\n\r\n[   41.506330] refcount_t: addition on 0; use-after-free.\n[   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130\n[   41.507413] Modules linked in: veth bridge stp llc\n[   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14\n[   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n[   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130\n[   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 \u0026lt;0f\u0026gt; 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff\n[   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282\n[   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000\n[   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900\n[   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff\n[   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000\n[   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48\n[   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000\n[   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0\n[   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[   41.516799] Call Trace:\n[   41.517037]  \u0026lt;TASK\u0026gt;\n[   41.517249]  ? __warn+0x7b/0x120\n[   41.517535]  ? refcount_warn_saturate+0xa5/0x130\n[   41.517923]  ? report_bug+0x164/0x190\n[   41.518240]  ? handle_bug+0x3d/0x70\n[   41.518541]  ? exc_invalid_op+0x17/0x70\n[   41.520972]  ? asm_exc_invalid_op+0x1a/0x20\n[   41.521325]  ? refcount_warn_saturate+0xa5/0x130\n[   41.521708]  ipv6_get_ifaddr+0xda/0xe0\n[   41.522035]  inet6_rtm_getaddr+0x342/0x3f0\n[   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10\n[   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0\n[   41.523102]  ? netlink_unicast+0x30f/0x390\n[   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[   41.523832]  netlink_rcv_skb+0x53/0x100\n[   41.524157]  netlink_unicast+0x23b/0x390\n[   41.524484]  netlink_sendmsg+0x1f2/0x440\n[   41.524826]  __sys_sendto+0x1d8/0x1f0\n[   41.525145]  __x64_sys_sendto+0x1f/0x30\n[   41.525467]  do_syscall_64+0xa5/0x1b0\n[   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a\n[   41.526213] RIP: 0033:0x7fbc4cfcea9a\n[   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89\n[   41.527942] RSP: 002b:00007f\n---truncated---(CVE-2024-35969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: honor table dormant flag from netdev release event path\r\n\r\nCheck for table dormant flag otherwise netdev release event path tries\nto unregister an already unregistered hook.\r\n\r\n[524854.857999] ------------[ cut here ]------------\n[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260\n[...]\n[524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365\n[524854.858869] Workqueue: netns cleanup_net\n[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260\n[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff \u0026lt;0f\u0026gt; 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41\n[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246\n[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a\n[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438\n[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34\n[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005\n[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00\n[524854.858971] FS:  0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[524854.858982] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0\n[524854.859000] Call Trace:\n[524854.859006]  \u0026lt;TASK\u0026gt;\n[524854.859013]  ? __warn+0x9f/0x1a0\n[524854.859027]  ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859044]  ? report_bug+0x1b1/0x1e0\n[524854.859060]  ? handle_bug+0x3c/0x70\n[524854.859071]  ? exc_invalid_op+0x17/0x40\n[524854.859083]  ? asm_exc_invalid_op+0x1a/0x20\n[524854.859100]  ? __nf_unregister_net_hook+0x6a/0x260\n[524854.859116]  ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859135]  nf_tables_netdev_event+0x337/0x390 [nf_tables]\n[524854.859304]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859461]  ? packet_notifier+0xb3/0x360\n[524854.859476]  ? _raw_spin_unlock_irqrestore+0x11/0x40\n[524854.859489]  ? dcbnl_netdevice_event+0x35/0x140\n[524854.859507]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859661]  notifier_call_chain+0x7d/0x140\n[524854.859677]  unregister_netdevice_many_notify+0x5e1/0xae0(CVE-2024-36005)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkeys: Fix overwrite of key expiration on instantiation\r\n\r\nThe expiry time of a key is unconditionally overwritten during\ninstantiation, defaulting to turn it permanent. This causes a problem\nfor DNS resolution as the expiration set by user-space is overwritten to\nTIME64_MAX, disabling further DNS updates. Fix this by restoring the\ncondition that key_set_expiry is only called when the pre-parser sets a\nspecific expiry.(CVE-2024-36031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: tproxy: bail out if IP has been disabled on the device\r\n\r\nsyzbot reports:\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n[..]\nRIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62\nCall Trace:\n nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]\n nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168\r\n\r\n__in_dev_get_rcu() can return NULL, so check for this.(CVE-2024-36270)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: qca: add missing firmware sanity checks\r\n\r\nAdd the missing sanity checks when parsing the firmware files before\ndownloading them to avoid accessing and corrupting memory beyond the\nvmalloced buffer.(CVE-2024-36880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: llcp: fix nfc_llcp_setsockopt() unsafe copies\r\n\r\nsyzbot reported unsafe calls to copy_from_sockptr() [1]\r\n\r\nUse copy_safe_from_sockptr() instead.\r\n\r\n[1]\r\n\r\nBUG: 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 nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255\nRead of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078\r\n\r\nCPU: 0 PID: 5078 Comm: syz-executor459 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 \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:488\n  kasan_report+0x143/0x180 mm/kasan/report.c:601\n  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n  copy_from_sockptr include/linux/sockptr.h:55 [inline]\n  nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255\n  do_sock_setsockopt+0x3b1/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+0xfd/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7f7fac07fd89\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89\nRDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000(CVE-2024-36915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul\ninstead of memdup_user.(CVE-2024-36934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet: fix rtm_phonet_notify() skb allocation\r\n\r\nfill_route() stores three components in the skb:\r\n\r\n- struct rtmsg\n- RTA_DST (u8)\n- RTA_OIF (u32)\r\n\r\nTherefore, rtm_phonet_notify() should use\r\n\r\nNLMSG_ALIGN(sizeof(struct rtmsg)) +\nnla_total_size(1) +\nnla_total_size(4)(CVE-2024-36946)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: vc4: Fix possible null pointer dereference\r\n\r\nIn vc4_hdmi_audio_init() of_get_address() may return\nNULL which is later dereferenced. Fix this bug by adding NULL check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bfa: Ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul instead\nof memdup_user.(CVE-2024-38560)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: i2c: et8ek8: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback\nbeing discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets\nunbound (e.g. using sysfs or hotplug), the driver is just removed\nwithout the cleanup being performed. This results in resource leaks. Fix\nit by compiling in the remove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\n\tWARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -\u0026gt; et8ek8_remove (section: .exit.text)(CVE-2024-38611)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nm68k: Fix spinlock race in kernel thread creation\r\n\r\nContext switching does take care to retain the correct lock owner across\nthe switch from \u0026apos;prev\u0026apos; to \u0026apos;next\u0026apos; tasks.  This does rely on interrupts\nremaining disabled for the entire duration of the switch.\r\n\r\nThis condition is guaranteed for normal process creation and context\nswitching between already running processes, because both \u0026apos;prev\u0026apos; and\n\u0026apos;next\u0026apos; already have interrupts disabled in their saved copies of the\nstatus register.\r\n\r\nThe situation is different for newly created kernel threads.  The status\nregister is set to PS_S in copy_thread(), which does leave the IPL at 0.\nUpon restoring the \u0026apos;next\u0026apos; thread\u0026apos;s status register in switch_to() aka\nresume(), interrupts then become enabled prematurely.  resume() then\nreturns via ret_from_kernel_thread() and schedule_tail() where run queue\nlock is released (see finish_task_switch() and finish_lock_switch()).\r\n\r\nA timer interrupt calling scheduler_tick() before the lock is released\nin finish_task_switch() will find the lock already taken, with the\ncurrent task as lock owner.  This causes a spinlock recursion warning as\nreported by Guenter Roeck.\r\n\r\nAs far as I can ascertain, this race has been opened in commit\n533e6903bea0 (\u0026quot;m68k: split ret_from_fork(), simplify kernel_thread()\u0026quot;)\nbut I haven\u0026apos;t done a detailed study of kernel history so it may well\npredate that commit.\r\n\r\nInterrupts cannot be disabled in the saved status register copy for\nkernel threads (init will complain about interrupts disabled when\nfinally starting user space).  Disable interrupts temporarily when\nswitching the tasks\u0026apos; register sets in resume().\r\n\r\nNote that a simple oriw 0x700,%sr after restoring sr is not enough here\n- this leaves enough of a race for the \u0026apos;spinlock recursion\u0026apos; warning to\nstill be observed.\r\n\r\nTested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nenic: Validate length of nl attributes in enic_set_vf_port\r\n\r\nenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE\nis of length PORT_PROFILE_MAX and that the nl attributes\nIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.\nThese attributes are validated (in the function do_setlink in rtnetlink.c)\nusing the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE\nas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and\nIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation\nusing the policy is for the max size of the attributes and not on exact\nsize so the length of these attributes might be less than the sizes that\nenic_set_vf_port expects. This might cause an out of bands\nread access in the memcpys of the data of these\nattributes in enic_set_vf_port.(CVE-2024-38659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: Add winch to winch_handlers before registering winch IRQ\r\n\r\nRegistering a winch IRQ is racy, an interrupt may occur before the winch is\nadded to the winch_handlers list.\r\n\r\nIf that happens, register_winch_irq() adds to that list a winch that is\nscheduled to be (or has already been) freed, causing a panic later in\nwinch_cleanup().\r\n\r\nAvoid the race by adding the winch to the winch_handlers list before\nregistering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nima: Fix use-after-free on a dentry\u0026apos;s dname.name\r\n\r\n-\u0026gt;d_name.name can change on rename and the earlier value can be freed;\nthere are conditions sufficient to stabilize it (-\u0026gt;d_lock on dentry,\n-\u0026gt;d_lock on its parent, -\u0026gt;i_rwsem exclusive on the parent\u0026apos;s inode,\nrename_lock), but none of those are met at any of the sites. Take a stable\nsnapshot of the name instead.(CVE-2024-39494)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/exynos/vidi: fix memory leak in .get_modes()\r\n\r\nThe duplicated EDID is never freed. Fix it.(CVE-2024-40932)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: fix UBSAN warning in kv_dpm.c\r\n\r\nAdds bounds check for sumo_vid_mapping_entry.(CVE-2024-40988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Validate ff offset\r\n\r\nThis adds sanity checks for ff offset. There is a check\non rt-\u0026gt;first_free at first, but walking through by ff\nwithout any check. If the second ff is a large offset.\nWe may encounter an out-of-bound read.(CVE-2024-41019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix UAF when resolving a clash\r\n\r\nKASAN reports the following UAF:\r\n\r\n BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]\n Read of size 1 at addr ffff888c07603600 by task handler130/6469\r\n\r\n Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  dump_stack_lvl+0x48/0x70\n  print_address_description.constprop.0+0x33/0x3d0\n  print_report+0xc0/0x2b0\n  kasan_report+0xd0/0x120\n  __asan_load1+0x6c/0x80\n  tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]\n  tcf_ct_act+0x886/0x1350 [act_ct]\n  tcf_action_exec+0xf8/0x1f0\n  fl_classify+0x355/0x360 [cls_flower]\n  __tcf_classify+0x1fd/0x330\n  tcf_classify+0x21c/0x3c0\n  sch_handle_ingress.constprop.0+0x2c5/0x500\n  __netif_receive_skb_core.constprop.0+0xb25/0x1510\n  __netif_receive_skb_list_core+0x220/0x4c0\n  netif_receive_skb_list_internal+0x446/0x620\n  napi_complete_done+0x157/0x3d0\n  gro_cell_poll+0xcf/0x100\n  __napi_poll+0x65/0x310\n  net_rx_action+0x30c/0x5c0\n  __do_softirq+0x14f/0x491\n  __irq_exit_rcu+0x82/0xc0\n  irq_exit_rcu+0xe/0x20\n  common_interrupt+0xa1/0xb0\n  \u0026lt;/IRQ\u0026gt;\n  \u0026lt;TASK\u0026gt;\n  asm_common_interrupt+0x27/0x40\r\n\r\n Allocated by task 6469:\n  kasan_save_stack+0x38/0x70\n  kasan_set_track+0x25/0x40\n  kasan_save_alloc_info+0x1e/0x40\n  __kasan_krealloc+0x133/0x190\n  krealloc+0xaa/0x130\n  nf_ct_ext_add+0xed/0x230 [nf_conntrack]\n  tcf_ct_act+0x1095/0x1350 [act_ct]\n  tcf_action_exec+0xf8/0x1f0\n  fl_classify+0x355/0x360 [cls_flower]\n  __tcf_classify+0x1fd/0x330\n  tcf_classify+0x21c/0x3c0\n  sch_handle_ingress.constprop.0+0x2c5/0x500\n  __netif_receive_skb_core.constprop.0+0xb25/0x1510\n  __netif_receive_skb_list_core+0x220/0x4c0\n  netif_receive_skb_list_internal+0x446/0x620\n  napi_complete_done+0x157/0x3d0\n  gro_cell_poll+0xcf/0x100\n  __napi_poll+0x65/0x310\n  net_rx_action+0x30c/0x5c0\n  __do_softirq+0x14f/0x491\r\n\r\n Freed by task 6469:\n  kasan_save_stack+0x38/0x70\n  kasan_set_track+0x25/0x40\n  kasan_save_free_info+0x2b/0x60\n  ____kasan_slab_free+0x180/0x1f0\n  __kasan_slab_free+0x12/0x30\n  slab_free_freelist_hook+0xd2/0x1a0\n  __kmem_cache_free+0x1a2/0x2f0\n  kfree+0x78/0x120\n  nf_conntrack_free+0x74/0x130 [nf_conntrack]\n  nf_ct_destroy+0xb2/0x140 [nf_conntrack]\n  __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]\n  nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]\n  __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]\n  tcf_ct_act+0x12ad/0x1350 [act_ct]\n  tcf_action_exec+0xf8/0x1f0\n  fl_classify+0x355/0x360 [cls_flower]\n  __tcf_classify+0x1fd/0x330\n  tcf_classify+0x21c/0x3c0\n  sch_handle_ingress.constprop.0+0x2c5/0x500\n  __netif_receive_skb_core.constprop.0+0xb25/0x1510\n  __netif_receive_skb_list_core+0x220/0x4c0\n  netif_receive_skb_list_internal+0x446/0x620\n  napi_complete_done+0x157/0x3d0\n  gro_cell_poll+0xcf/0x100\n  __napi_poll+0x65/0x310\n  net_rx_action+0x30c/0x5c0\n  __do_softirq+0x14f/0x491\r\n\r\nThe ct may be dropped if a clash has been resolved but is still passed to\nthe tcf_ct_flow_table_process_conn function for further usage. This issue\ncan be fixed by retrieving ct from skb again after confirming conntrack.(CVE-2024-41040)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().\r\n\r\nsyzkaller triggered the warning [0] in udp_v4_early_demux().\r\n\r\nIn udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount\nof the looked-up sk and use sock_pfree() as skb-\u0026gt;destructor, so we check\nSOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace\nperiod.\r\n\r\nCurrently, SOCK_RCU_FREE is flagged for a bound socket after being put\ninto the hash table.  Moreover, the SOCK_RCU_FREE check is done too early\nin udp_v[46]_early_demux() and sk_lookup(), so there could be a small race\nwindow:\r\n\r\n  CPU1                                 CPU2\n  ----                                 ----\n  udp_v4_early_demux()                 udp_lib_get_port()\n  |                                    |- hlist_add_head_rcu()\n  |- sk = __udp4_lib_demux_lookup()    |\n  |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));\n                                       `- sock_set_flag(sk, SOCK_RCU_FREE)\r\n\r\nWe had the same bug in TCP and fixed it in commit 871019b22d1b (\u0026quot;net:\nset SOCK_RCU_FREE before inserting socket into hashtable\u0026quot;).\r\n\r\nLet\u0026apos;s apply the same fix for UDP.\r\n\r\n[0]:\nWARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599\nModules linked in:\nCPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599\nCode: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe \u0026lt;0f\u0026gt; 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52\nRSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c\nRDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001\nRBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680\nR13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e\nFS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349\n ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netfilter.h:308 [inline]\n ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624\n __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738\n netif_receive_skb_internal net/core/dev.c:5824 [inline]\n netif_receive_skb+0x271/0x300 net/core/dev.c:5884\n tun_rx_batched drivers/net/tun.c:1549 [inline]\n tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002\n tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x76f/0x8d0 fs/read_write.c:590\n ksys_write+0xbf/0x190 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+0x41/0x50 fs/read_write.c:652\n x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fc44a68bc1f\nCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48\nRSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f\nR\n---truncated---(CVE-2024-41041)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nskmsg: Skip zero length skb in sk_msg_recvmsg\r\n\r\nWhen running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch\nplatform, the following kernel panic occurs:\r\n\r\n  [...]\n  Oops[#1]:\n  CPU: 22 PID: 2824 Comm: test_progs Tainted: G           OE  6.10.0-rc2+ #18\n  Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018\n     ... ...\n     ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560\n    ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0\n   CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n   PRMD: 0000000c (PPLV0 +PIE +PWE)\n   EUEN: 00000007 (+FPE +SXE +ASXE -BTE)\n   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)\n  ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)\n   BADV: 0000000000000040\n   PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)\n  Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack\n  Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)\n  Stack : ...\n  Call Trace:\n  [\u0026lt;9000000004162774\u0026gt;] copy_page_to_iter+0x74/0x1c0\n  [\u0026lt;90000000048bf6c0\u0026gt;] sk_msg_recvmsg+0x120/0x560\n  [\u0026lt;90000000049f2b90\u0026gt;] tcp_bpf_recvmsg_parser+0x170/0x4e0\n  [\u0026lt;90000000049aae34\u0026gt;] inet_recvmsg+0x54/0x100\n  [\u0026lt;900000000481ad5c\u0026gt;] sock_recvmsg+0x7c/0xe0\n  [\u0026lt;900000000481e1a8\u0026gt;] __sys_recvfrom+0x108/0x1c0\n  [\u0026lt;900000000481e27c\u0026gt;] sys_recvfrom+0x1c/0x40\n  [\u0026lt;9000000004c076ec\u0026gt;] do_syscall+0x8c/0xc0\n  [\u0026lt;9000000003731da4\u0026gt;] handle_syscall+0xc4/0x160\n  Code: ...\n  ---[ end trace 0000000000000000 ]---\n  Kernel panic - not syncing: Fatal exception\n  Kernel relocated by 0x3510000\n   .text @ 0x9000000003710000\n   .data @ 0x9000000004d70000\n   .bss  @ 0x9000000006469400\n  ---[ end Kernel panic - not syncing: Fatal exception ]---\n  [...]\r\n\r\nThis crash happens every time when running sockmap_skb_verdict_shutdown\nsubtest in sockmap_basic.\r\n\r\nThis crash is because a NULL pointer is passed to page_address() in the\nsk_msg_recvmsg(). Due to the different implementations depending on the\narchitecture, page_address(NULL) will trigger a panic on Loongarch\nplatform but not on x86 platform. So this bug was hidden on x86 platform\nfor a while, but now it is exposed on Loongarch platform. The root cause\nis that a zero length skb (skb-\u0026gt;len == 0) was put on the queue.\r\n\r\nThis zero length skb is a TCP FIN packet, which was sent by shutdown(),\ninvoked in test_sockmap_skb_verdict_shutdown():\r\n\r\n\tshutdown(p1, SHUT_WR);\r\n\r\nIn this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no\npage is put to this sge (see sg_set_page in sg_set_page), but this empty\nsge is queued into ingress_msg list.\r\n\r\nAnd in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by\nsg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it\nto kmap_local_page() and to page_address(), then kernel panics.\r\n\r\nTo solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),\nif copy is zero, that means it\u0026apos;s a zero length skb, skip invoking\ncopy_page_to_iter(). We are using the EFAULT return triggered by\ncopy_page_to_iter to check for is_fin in tcp_bpf.c.(CVE-2024-41048)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: fix potential use-after-free in posix_lock_inode\r\n\r\nLight Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().\nThe request pointer had been changed earlier to point to a lock entry\nthat was added to the inode\u0026apos;s list. However, before the tracepoint could\nfire, another task raced in and freed that lock.\r\n\r\nFix this by moving the tracepoint inside the spinlock, which should\nensure that this doesn\u0026apos;t happen.(CVE-2024-41049)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: hci_core: cancel all works upon hci_unregister_dev()\r\n\r\nsyzbot is reporting that calling hci_release_dev() from hci_error_reset()\ndue to hci_dev_put() from hci_error_reset() can cause deadlock at\ndestroy_workqueue(), for hci_error_reset() is called from\nhdev-\u0026gt;req_workqueue which destroy_workqueue() needs to flush.\r\n\r\nWe need to make sure that hdev-\u0026gt;{rx_work,cmd_work,tx_work} which are\nqueued into hdev-\u0026gt;workqueue and hdev-\u0026gt;{power_on,error_reset} which are\nqueued into hdev-\u0026gt;req_workqueue are no longer running by the moment\r\n\r\n       destroy_workqueue(hdev-\u0026gt;workqueue);\n       destroy_workqueue(hdev-\u0026gt;req_workqueue);\r\n\r\nare called from hci_release_dev().\r\n\r\nCall cancel_work_sync() on these work items from hci_unregister_dev()\nas soon as hdev-\u0026gt;list is removed from hci_dev_list.(CVE-2024-41063)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: topology: Fix references to freed memory\r\n\r\nMost users after parsing a topology file, release memory used by it, so\nhaving pointer references directly into topology file contents is wrong.\nUse devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: fix possible deadlock in io_register_iowq_max_workers()\r\n\r\nThe io_register_iowq_max_workers() function calls io_put_sq_data(),\nwhich acquires the sqd-\u0026gt;lock without releasing the uring_lock.\nSimilar to the commit 009ad9f0c6ee (\u0026quot;io_uring: drop ctx-\u0026gt;uring_lock\nbefore acquiring sqd-\u0026gt;lock\u0026quot;), this can lead to a potential deadlock\nsituation.\r\n\r\nTo resolve this issue, the uring_lock is released before calling\nio_put_sq_data(), and then it is re-acquired after the function call.\r\n\r\nThis change ensures that the locks are acquired in the correct\norder, preventing the possibility of a deadlock.(CVE-2024-41080)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntap: add missing verification for short frame\r\n\r\nThe cited commit missed to check against the validity of the frame length\nin the tap_get_user_xdp() path, which could cause a corrupted skb to be\nsent downstack. Even before the skb is transmitted, the\ntap_get_user_xdp()--\u0026gt;skb_set_network_header() may assume the size is more\nthan ETH_HLEN. Once transmitted, this could either cause out-of-bound\naccess beyond the actual length, or confuse the underlayer with incorrect\nor inconsistent header length in the skb metadata.\r\n\r\nIn the alternative path, tap_get_user() already prohibits short frame which\nhas the length less than Ethernet header size from being transmitted.\r\n\r\nThis is to drop any frame shorter than the Ethernet header size just like\nhow tap_get_user() does.\r\n\r\nCVE: CVE-2024-41090(CVE-2024-41090)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntun: add missing verification for short frame\r\n\r\nThe cited commit missed to check against the validity of the frame length\nin the tun_xdp_one() path, which could cause a corrupted skb to be sent\ndownstack. Even before the skb is transmitted, the\ntun_xdp_one--\u0026gt;eth_type_trans() may access the Ethernet header although it\ncan be less than ETH_HLEN. Once transmitted, this could either cause\nout-of-bound access beyond the actual length, or confuse the underlayer\nwith incorrect or inconsistent header length in the skb metadata.\r\n\r\nIn the alternative path, tun_get_user() already prohibits short frame which\nhas the length less than Ethernet header size from being transmitted for\nIFF_TAP.\r\n\r\nThis is to drop any frame shorter than the Ethernet header size just like\nhow tun_get_user() does.\r\n\r\nCVE: CVE-2024-41091(CVE-2024-41091)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\r\n\r\nset_memory_rox() can fail, leaving memory unprotected.\r\n\r\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.(CVE-2024-42067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: chemical: bme680: Fix overflows in compensate() functions\r\n\r\nThere are cases in the compensate functions of the driver that\nthere could be overflows of variables due to bit shifting ops.\nThese implications were initially discussed here [1] and they\nwere mentioned in log message of Commit 1b3bd8592780 (\u0026quot;iio:\nchemical: Add support for Bosch BME680 sensor\u0026quot;).\r\n\r\n[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/(CVE-2024-42086)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: emux: improve patch ioctl data validation\r\n\r\nIn load_data(), make the validation of and skipping over the main info\nblock match that in load_guspatch().\r\n\r\nIn load_guspatch(), add checking that the specified patch length matches\nthe actually supplied data, like load_data() already did.(CVE-2024-42097)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njffs2: Fix potential illegal address access in jffs2_free_inode\r\n\r\nDuring the stress testing of the jffs2 file system,the following\nabnormal printouts were found:\n[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948\n[ 2430.649622] Mem abort info:\n[ 2430.649829]   ESR = 0x96000004\n[ 2430.650115]   EC = 0x25: DABT (current EL), IL = 32 bits\n[ 2430.650564]   SET = 0, FnV = 0\n[ 2430.650795]   EA = 0, S1PTW = 0\n[ 2430.651032]   FSC = 0x04: level 0 translation fault\n[ 2430.651446] Data abort info:\n[ 2430.651683]   ISV = 0, ISS = 0x00000004\n[ 2430.652001]   CM = 0, WnR = 0\n[ 2430.652558] [0069696969696948] address between user and kernel address ranges\n[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP\n[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33\n[ 2430.655008] Hardware name: linux,dummy-virt (DT)\n[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 2430.656142] pc : kfree+0x78/0x348\n[ 2430.656630] lr : jffs2_free_inode+0x24/0x48\n[ 2430.657051] sp : ffff800009eebd10\n[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000\n[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000\n[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14\n[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000\n[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000\n[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19\n[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14\n[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302\n[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342\n[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000\n[ 2430.664217] Call trace:\n[ 2430.664528]  kfree+0x78/0x348\n[ 2430.664855]  jffs2_free_inode+0x24/0x48\n[ 2430.665233]  i_callback+0x24/0x50\n[ 2430.665528]  rcu_do_batch+0x1ac/0x448\n[ 2430.665892]  rcu_core+0x28c/0x3c8\n[ 2430.666151]  rcu_core_si+0x18/0x28\n[ 2430.666473]  __do_softirq+0x138/0x3cc\n[ 2430.666781]  irq_exit+0xf0/0x110\n[ 2430.667065]  handle_domain_irq+0x6c/0x98\n[ 2430.667447]  gic_handle_irq+0xac/0xe8\n[ 2430.667739]  call_on_irq_stack+0x28/0x54\nThe parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of\nthe jffs_inode_info structure. It was found that all variables in the jffs_inode_info\nstructure were 5a5a5a5a, except for the first member sem. It is suspected that these\nvariables are not initialized because they were set to 5a5a5a5a during memory testing,\nwhich is meant to detect uninitialized memory.The sem variable is initialized in the\nfunction jffs2_i_init_once, while other members are initialized in\nthe function jffs2_init_inode_info.\r\n\r\nThe function jffs2_init_inode_info is called after iget_locked,\nbut in the iget_locked function, the destroy_inode process is triggered,\nwhich releases the inode and consequently, the target member of the inode\nis not initialized.In concurrent high pressure scenarios, iget_locked\nmay enter the destroy_inode branch as described in the code.\r\n\r\nSince the destroy_inode functionality of jffs2 only releases the target,\nthe fix method is to set target to NULL in jffs2_i_init_once.(CVE-2024-42115)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: mlxreg: Use devm_mutex_init() for mutex initialization\r\n\r\nIn this driver LEDs are registered using devm_led_classdev_register()\nso they are automatically unregistered after module\u0026apos;s remove() is done.\nled_classdev_unregister() calls module\u0026apos;s led_set_brightness() to turn off\nthe LEDs and that callback uses mutex which was destroyed already\nin module\u0026apos;s remove() so use devm API instead.(CVE-2024-42129)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc\r\n\r\nInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.\nV2: To really improve the handling we would actually\n   need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nexthop: Initialize all fields in dumped nexthops\r\n\r\nstruct nexthop_grp contains two reserved fields that are not initialized by\nnla_put_nh_group(), and carry garbage. This can be observed e.g. with\nstrace (edited for clarity):\r\n\r\n    # ip nexthop add id 1 dev lo\n    # ip nexthop add id 101 group 1\n    # strace -e recvmsg ip nexthop get id 101\n    ...\n    recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},\n                 [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52\r\n\r\nThe fields are reserved and therefore not currently used. But as they are, they\nleak kernel memory, and the fact they are not just zero complicates repurposing\nof the fields for new ends. Initialize the full structure.(CVE-2024-42283)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nirqchip/imx-irqsteer: Handle runtime power management correctly\r\n\r\nThe power domain is automatically activated from clk_prepare(). However, on\ncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes\nsleeping functions, which triggers the \u0026apos;scheduling while atomic\u0026apos; bug in the\ncontext switch path during device probing:\r\n\r\n BUG: scheduling while atomic: kworker/u13:1/48/0x00000002\n Call trace:\n  __schedule_bug+0x54/0x6c\n  __schedule+0x7f0/0xa94\n  schedule+0x5c/0xc4\n  schedule_preempt_disabled+0x24/0x40\n  __mutex_lock.constprop.0+0x2c0/0x540\n  __mutex_lock_slowpath+0x14/0x20\n  mutex_lock+0x48/0x54\n  clk_prepare_lock+0x44/0xa0\n  clk_prepare+0x20/0x44\n  imx_irqsteer_resume+0x28/0xe0\n  pm_generic_runtime_resume+0x2c/0x44\n  __genpd_runtime_resume+0x30/0x80\n  genpd_runtime_resume+0xc8/0x2c0\n  __rpm_callback+0x48/0x1d8\n  rpm_callback+0x6c/0x78\n  rpm_resume+0x490/0x6b4\n  __pm_runtime_resume+0x50/0x94\n  irq_chip_pm_get+0x2c/0xa0\n  __irq_do_set_handler+0x178/0x24c\n  irq_set_chained_handler_and_data+0x60/0xa4\n  mxc_gpio_probe+0x160/0x4b0\r\n\r\nCure this by implementing the irq_bus_lock/sync_unlock() interrupt chip\ncallbacks and handle power management in them as they are invoked from\nnon-atomic context.\r\n\r\n[ tglx: Rewrote change log, added Fixes tag ](CVE-2024-42290)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid using corrupted block bitmap buffer\r\n\r\nWhen the filesystem block bitmap is corrupted, we detect the corruption\nwhile loading the bitmap and fail the allocation with error. However the\nnext allocation from the same bitmap will notice the bitmap buffer is\nalready loaded and tries to allocate from the bitmap with mixed results\n(depending on the exact nature of the bitmap corruption). Fix the\nproblem by using BH_verified bit to indicate whether the bitmap is valid\nor not.(CVE-2024-42306)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes\r\n\r\nIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42309)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: venus: fix use after free in vdec_close\r\n\r\nThere appears to be a possible use after free with vdec_close().\nThe firmware will add buffer release work to the work queue through\nHFI callbacks as a normal part of decoding. Randomly closing the\ndecoder device from userspace during normal decoding can incur\na read after free for inst.\r\n\r\nFix it by cancelling the work in vdec_close.(CVE-2024-42313)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvs: properly dereference pe in ip_vs_add_service\r\n\r\nUse pe directly to resolve sparse warning:\r\n\r\n  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()\r\n\r\nIf IORESOURCE_MEM is not provided in Device Tree due to\nany error, resource_list_first_type() will return NULL and\npci_parse_request_of_pci_ranges() will just emit a warning.\r\n\r\nThis will cause a NULL pointer dereference. Fix this bug by adding NULL\nreturn check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: trigger: Unregister sysfs attributes before calling deactivate()\r\n\r\nTriggers which have trigger specific sysfs attributes typically store\nrelated data in trigger-data allocated by the activate() callback and\nfreed by the deactivate() callback.\r\n\r\nCalling device_remove_groups() after calling deactivate() leaves a window\nwhere the sysfs attributes show/store functions could be called after\ndeactivation and then operate on the just freed trigger-data.\r\n\r\nMove the device_remove_groups() call to before deactivate() to close\nthis race window.\r\n\r\nThis also makes the deactivation path properly do things in reverse order\nof the activation path which calls the activate() callback before calling\ndevice_add_groups().(CVE-2024-43830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG\r\n\r\nWhen BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls\n__bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them\nthe struct bpf_tramp_image *im pointer as an argument in R0.\r\n\r\nThe trampoline generation code uses emit_addr_mov_i64() to emit\ninstructions for moving the bpf_tramp_image address into R0, but\nemit_addr_mov_i64() assumes the address to be in the vmalloc() space\nand uses only 48 bits. Because bpf_tramp_image is allocated using\nkzalloc(), its address can use more than 48-bits, in this case the\ntrampoline will pass an invalid address to __bpf_tramp_enter/exit()\ncausing a kernel crash.\r\n\r\nFix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64()\nas it can work with addresses that are greater than 48-bits.(CVE-2024-43840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix deadlock between mddev_suspend and flush bio\r\n\r\nDeadlock occurs when mddev is being suspended while some flush bio is in\nprogress. It is a complex issue.\r\n\r\nT1. the first flush is at the ending stage, it clears \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;\n    and tries to submit data, but is blocked because mddev is suspended\n    by T4.\nT2. the second flush sets \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;, and attempts to queue\n    md_submit_flush_data(), which is already running (T1) and won\u0026apos;t\n    execute again if on the same CPU as T1.\nT3. the third flush inc active_io and tries to flush, but is blocked because\n    \u0026apos;mddev-\u0026gt;flush_bio\u0026apos; is not NULL (set by T2).\nT4. mddev_suspend() is called and waits for active_io dec to 0 which is inc\n    by T3.\r\n\r\n  T1\t\tT2\t\tT3\t\tT4\n  (flush 1)\t(flush 2)\t(third 3)\t(suspend)\n  md_submit_flush_data\n   mddev-\u0026gt;flush_bio = NULL;\n   .\n   .\t \tmd_flush_request\n   .\t  \t mddev-\u0026gt;flush_bio = bio\n   .\t  \t queue submit_flushes\n   .\t\t .\n   .\t\t .\t\tmd_handle_request\n   .\t\t .\t\t active_io + 1\n   .\t\t .\t\t md_flush_request\n   .\t\t .\t\t  wait !mddev-\u0026gt;flush_bio\n   .\t\t .\n   .\t\t .\t\t\t\tmddev_suspend\n   .\t\t .\t\t\t\t wait !active_io\n   .\t\t .\n   .\t\t submit_flushes\n   .\t\t queue_work md_submit_flush_data\n   .\t\t //md_submit_flush_data is already running (T1)\n   .\n   md_handle_request\n    wait resume\r\n\r\nThe root issue is non-atomic inc/dec of active_io during flush process.\nactive_io is dec before md_submit_flush_data is queued, and inc soon\nafter md_submit_flush_data() run.\n  md_flush_request\n    active_io + 1\n    submit_flushes\n      active_io - 1\n      md_submit_flush_data\n        md_handle_request\n        active_io + 1\n          make_request\n        active_io - 1\r\n\r\nIf active_io is dec after md_handle_request() instead of within\nsubmit_flushes(), make_request() can be called directly intead of\nmd_handle_request() in md_submit_flush_data(), and active_io will\nonly inc and dec once in the whole flush process. Deadlock will be\nfixed.\r\n\r\nAdditionally, the only difference between fixing the issue and before is\nthat there is no return error handling of make_request(). But after\nprevious patch cleaned md_write_start(), make_requst() only return error\nin raid5_make_request() by dm-raid, see commit 41425f96d7aa (\u0026quot;dm-raid456,\nmd/raid456: fix a deadlock for dm-raid456 while io concurrent with\nreshape)\u0026quot;. Since dm always splits data and flush operation into two\nseparate io, io size of flush submitted by dm always is 0, make_request()\nwill not be called in md_submit_flush_data(). To prevent future\nmodifications from introducing issues, add WARN_ON to ensure\nmake_request() no error is returned in this context.(CVE-2024-43855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/hns: Fix soft lockup under heavy CEQE load\r\n\r\nCEQEs are handled in interrupt handler currently. This may cause the\nCPU core staying in interrupt context too long and lead to soft lockup\nunder heavy load.\r\n\r\nHandle CEQEs in BH workqueue and set an upper limit for the number of\nCEQE handled by a single call of work handler.(CVE-2024-43872)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg: protect concurrent access to mem_cgroup_idr\r\n\r\nCommit 73f576c04b94 (\u0026quot;mm: memcontrol: fix cgroup creation failure after\nmany small jobs\u0026quot;) decoupled the memcg IDs from the CSS ID space to fix the\ncgroup creation failures.  It introduced IDR to maintain the memcg ID\nspace.  The IDR depends on external synchronization mechanisms for\nmodifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()\nhappen within css callback and thus are protected through cgroup_mutex\nfrom concurrent modifications.  However idr_remove() for mem_cgroup_idr\nwas not protected against concurrency and can be run concurrently for\ndifferent memcgs when they hit their refcnt to zero.  Fix that.\r\n\r\nWe have been seeing list_lru based kernel crashes at a low frequency in\nour fleet for a long time.  These crashes were in different part of\nlist_lru code including list_lru_add(), list_lru_del() and reparenting\ncode.  Upon further inspection, it looked like for a given object (dentry\nand inode), the super_block\u0026apos;s list_lru didn\u0026apos;t have list_lru_one for the\nmemcg of that object.  The initial suspicions were either the object is\nnot allocated through kmem_cache_alloc_lru() or somehow\nmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but\nreturned success.  No evidence were found for these cases.\r\n\r\nLooking more deeply, we started seeing situations where valid memcg\u0026apos;s id\nis not present in mem_cgroup_idr and in some cases multiple valid memcgs\nhave same id and mem_cgroup_idr is pointing to one of them.  So, the most\nreasonable explanation is that these situations can happen due to race\nbetween multiple idr_remove() calls or race between\nidr_alloc()/idr_replace() and idr_remove().  These races are causing\nmultiple memcgs to acquire the same ID and then offlining of one of them\nwould cleanup list_lrus on the system for all of them.  Later access from\nother memcgs to the list_lru cause crashes due to missing list_lru_one.(CVE-2024-43892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: core: check uartclk for zero to avoid divide by zero\r\n\r\nCalling ioctl TIOCSSERIAL with an invalid baud_base can\nresult in uartclk being zero, which will result in a\ndivide by zero error in uart_get_divisor(). The check for\nuartclk being zero in uart_set_info() needs to be done\nbefore other settings are made as subsequent calls to\nioctl TIOCSSERIAL for the same port would be impacted if\nthe uartclk check was done where uartclk gets set.\r\n\r\nOops: divide error: 0000  PREEMPT SMP KASAN PTI\nRIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)\nCall Trace:\n \u0026lt;TASK\u0026gt;\nserial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576\n    drivers/tty/serial/8250/8250_port.c:2589)\nserial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502\n    drivers/tty/serial/8250/8250_port.c:2741)\nserial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)\nuart_change_line_settings (./include/linux/spinlock.h:376\n    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)\nuart_port_startup (drivers/tty/serial/serial_core.c:342)\nuart_startup (drivers/tty/serial/serial_core.c:368)\nuart_set_info (drivers/tty/serial/serial_core.c:1034)\nuart_set_info_user (drivers/tty/serial/serial_core.c:1059)\ntty_set_serial (drivers/tty/tty_io.c:2637)\ntty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)\n__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907\n    fs/ioctl.c:893 fs/ioctl.c:893)\ndo_syscall_64 (arch/x86/entry/common.c:52\n    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nRule: add(CVE-2024-43893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfou: remove warn in gue_gro_receive on unsupported protocol\r\n\r\nDrop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is\nnot known or does not have a GRO handler.\r\n\r\nSuch a packet is easily constructed. Syzbot generates them and sets\noff this warning.\r\n\r\nRemove the warning as it is expected and not actionable.\r\n\r\nThe warning was previously reduced from WARN_ON to WARN_ON_ONCE in\ncommit 270136613bf7 (\u0026quot;fou: Do WARN_ON_ONCE in gue_gro_receive for bad\nproto callbacks\u0026quot;).(CVE-2024-44940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: line6: Fix racy access to midibuf\r\n\r\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\r\n\r\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races.(CVE-2024-44954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natm: idt77252: prevent use after free in dequeue_rx()\r\n\r\nWe can\u0026apos;t dereference \u0026quot;skb\u0026quot; after calling vcc-\u0026gt;push() because the skb\nis released.(CVE-2024-44998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix Panther point NULL pointer deref at full-speed re-enumeration\r\n\r\nre-enumerating full-speed devices after a failed address device command\ncan trigger a NULL pointer dereference.\r\n\r\nFull-speed devices may need to reconfigure the endpoint 0 Max Packet Size\nvalue during enumeration. Usb core calls usb_ep0_reinit() in this case,\nwhich ends up calling xhci_configure_endpoint().\r\n\r\nOn Panther point xHC the xhci_configure_endpoint() function will\nadditionally check and reserve bandwidth in software. Other hosts do\nthis in hardware\r\n\r\nIf xHC address device command fails then a new xhci_virt_device structure\nis allocated as part of re-enabling the slot, but the bandwidth table\npointers are not set up properly here.\nThis triggers the NULL pointer dereference the next time usb_ep0_reinit()\nis called and xhci_configure_endpoint() tries to check and reserve\nbandwidth\r\n\r\n[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd\n[46710.713699] usb 3-1: Device not responding to setup address.\n[46710.917684] usb 3-1: Device not responding to setup address.\n[46711.125536] usb 3-1: device not accepting address 5, error -71\n[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[46711.125600] #PF: supervisor read access in kernel mode\n[46711.125603] #PF: error_code(0x0000) - not-present page\n[46711.125606] PGD 0 P4D 0\n[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI\n[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1\n[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.\n[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]\n[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c\r\n\r\nFix this by making sure bandwidth table pointers are set up correctly\nafter a failed address device command, and additionally by avoiding\nchecking for bandwidth in cases like this where no actual endpoints are\nadded or removed, i.e. only context for default control endpoint 0 is\nevaluated.(CVE-2024-45006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix error recovery leading to data corruption on ESE devices\r\n\r\nExtent Space Efficient (ESE) or thin provisioned volumes need to be\nformatted on demand during usual IO processing.\r\n\r\nThe dasd_ese_needs_format function checks for error codes that signal\nthe non existence of a proper track format.\r\n\r\nThe check for incorrect length is to imprecise since other error cases\nleading to transport of insufficient data also have this flag set.\nThis might lead to data corruption in certain error cases for example\nduring a storage server warmstart.\r\n\r\nFix by removing the check for incorrect length and replacing by\nexplicitly checking for invalid track format in transport mode.\r\n\r\nAlso remove the check for file protected since this is not a valid\nESE handling case.(CVE-2024-45026)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: pn533: Add poll mod list filling check\r\n\r\nIn case of im_protocols value is 1 and tm_protocols value is 0 this\ncombination successfully passes the check\n\u0026apos;if (!im_protocols \u0026amp;\u0026amp; !tm_protocols)\u0026apos; in the nfc_start_poll().\nBut then after pn533_poll_create_mod_list() call in pn533_start_poll()\npoll mod list will remain empty and dev-\u0026gt;poll_mod_count will remain 0\nwhich lead to division by zero.\r\n\r\nNormally no im protocol has value 1 in the mask, so this combination is\nnot expected by driver. But these protocol values actually come from\nuserspace via Netlink interface (NFC_CMD_START_POLL operation). So a\nbroken or malicious program may pass a message containing a \u0026quot;bad\u0026quot;\ncombination of protocol parameter values so that dev-\u0026gt;poll_mod_count\nis not incremented inside pn533_poll_create_mod_list(), thus leading\nto division by zero.\nCall trace looks like:\nnfc_genl_start_poll()\n  nfc_start_poll()\n    -\u0026gt;start_poll()\n    pn533_start_poll()\r\n\r\nAdd poll mod list filling check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: ucsi: Fix null pointer dereference in trace\r\n\r\nucsi_register_altmode checks IS_ERR for the alt pointer and treats\nNULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,\nucsi_register_displayport returns NULL which causes a NULL pointer\ndereference in trace. Rather than return NULL, call\ntypec_port_register_altmode to register DisplayPort alternate mode\nas a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Remove tst_run from lwt_seg6local_prog_ops.\r\n\r\nThe syzbot reported that the lwt_seg6 related BPF ops can be invoked\nvia bpf_test_run() without without entering input_action_end_bpf()\nfirst.\r\n\r\nMartin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL\nprobably didn\u0026apos;t work since it was introduced in commit 04d4b274e2a\n(\u0026quot;ipv6: sr: Add seg6local action End.BPF\u0026quot;). The reason is that the\nper-CPU variable seg6_bpf_srh_states::srh is never assigned in the self\ntest case but each BPF function expects it.\r\n\r\nRemove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.(CVE-2024-46754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Add netif_device_attach/detach into PF reset flow\r\n\r\nEthtool callbacks can be executed while reset is in progress and try to\naccess deleted resources, e.g. getting coalesce settings can result in a\nNULL pointer dereference seen below.\r\n\r\nReproduction steps:\nOnce the driver is fully initialized, trigger reset:\n\t# echo 1 \u0026gt; /sys/class/net/\u0026lt;interface\u0026gt;/device/reset\nwhen reset is in progress try to get coalesce settings using ethtool:\n\t# ethtool -c \u0026lt;interface\u0026gt;\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000020\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP PTI\nCPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7\nRIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]\nRSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206\nRAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000\nR13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40\nFS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0\nCall Trace:\n\u0026lt;TASK\u0026gt;\nice_get_coalesce+0x17/0x30 [ice]\ncoalesce_prepare_data+0x61/0x80\nethnl_default_doit+0xde/0x340\ngenl_family_rcv_msg_doit+0xf2/0x150\ngenl_rcv_msg+0x1b3/0x2c0\nnetlink_rcv_skb+0x5b/0x110\ngenl_rcv+0x28/0x40\nnetlink_unicast+0x19c/0x290\nnetlink_sendmsg+0x222/0x490\n__sys_sendto+0x1df/0x1f0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x82/0x160\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7faee60d8e27\r\n\r\nCalling netif_device_detach() before reset makes the net core not call\nthe driver when ethtool command is issued, the attempt to execute an\nethtool command during reset will result in the following message:\r\n\r\n    netlink error: No such device\r\n\r\ninstead of NULL pointer dereference. Once reset is done and\nice_rebuild() is executing, the netif_device_attach() is called to allow\nfor ethtool operations to occur again in a safe manner.(CVE-2024-46770)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: unset the binding mark of a reused connection\r\n\r\nSteve French reported null pointer dereference error from sha256 lib.\ncifs.ko can send session setup requests on reused connection.\nIf reused connection is used for binding session, conn-\u0026gt;binding can\nstill remain true and generate_preauth_hash() will not set\nsess-\u0026gt;Preauth_HashValue and it will be NULL.\nIt is used as a material to create an encryption key in\nksmbd_gen_smb311_encryptionkey. -\u0026gt;Preauth_HashValue cause null pointer\ndereference error from crypto_shash_update().\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 8 PID: 429254 Comm: kworker/8:39\nHardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )\nWorkqueue: ksmbd-io handle_ksmbd_work [ksmbd]\nRIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n\u0026lt;TASK\u0026gt;\n? show_regs+0x6d/0x80\n? __die+0x24/0x80\n? page_fault_oops+0x99/0x1b0\n? do_user_addr_fault+0x2ee/0x6b0\n? exc_page_fault+0x83/0x1b0\n? asm_exc_page_fault+0x27/0x30\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n_sha256_update+0x77/0xa0 [sha256_ssse3]\nsha256_avx2_update+0x15/0x30 [sha256_ssse3]\ncrypto_shash_update+0x1e/0x40\nhmac_update+0x12/0x20\ncrypto_shash_update+0x1e/0x40\ngenerate_key+0x234/0x380 [ksmbd]\ngenerate_smb3encryptionkey+0x40/0x1c0 [ksmbd]\nksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]\nntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]\nsmb2_sess_setup+0x952/0xaa0 [ksmbd]\n__process_request+0xa3/0x1d0 [ksmbd]\n__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]\nhandle_ksmbd_work+0x2d/0xa0 [ksmbd]\nprocess_one_work+0x16c/0x350\nworker_thread+0x306/0x440\n? __pfx_worker_thread+0x10/0x10\nkthread+0xef/0x120\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x44/0x70\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1b/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2024-46795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: the warning dereferencing obj for nbio_v7_4\r\n\r\nif ras_manager obj null, don\u0026apos;t print NBIO err data(CVE-2024-46819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nELF: fix kernel.randomize_va_space double read\r\n\r\nELF loader uses \u0026quot;randomize_va_space\u0026quot; twice. It is sysctl and can change\nat any moment, so 2 loads could see 2 different values in theory with\nunpredictable consequences.\r\n\r\nIssue exactly one load for consistent value across one exec.(CVE-2024-46826)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched: sch_cake: fix bulk flow accounting logic for host fairness\r\n\r\nIn sch_cake, we keep track of the count of active bulk flows per host,\nwhen running in dst/src host fairness mode, which is used as the\nround-robin weight when iterating through flows. The count of active\nbulk flows is updated whenever a flow changes state.\r\n\r\nThis has a peculiar interaction with the hash collision handling: when a\nhash collision occurs (after the set-associative hashing), the state of\nthe hash bucket is simply updated to match the new packet that collided,\nand if host fairness is enabled, that also means assigning new per-host\nstate to the flow. For this reason, the bulk flow counters of the\nhost(s) assigned to the flow are decremented, before new state is\nassigned (and the counters, which may not belong to the same host\nanymore, are incremented again).\r\n\r\nBack when this code was introduced, the host fairness mode was always\nenabled, so the decrement was unconditional. When the configuration\nflags were introduced the *increment* was made conditional, but\nthe *decrement* was not. Which of course can lead to a spurious\ndecrement (and associated wrap-around to U16_MAX).\r\n\r\nAFAICT, when host fairness is disabled, the decrement and wrap-around\nhappens as soon as a hash collision occurs (which is not that common in\nitself, due to the set-associative hashing). However, in most cases this\nis harmless, as the value is only used when host fairness mode is\nenabled. So in order to trigger an array overflow, sch_cake has to first\nbe configured with host fairness disabled, and while running in this\nmode, a hash collision has to occur to cause the overflow. Then, the\nqdisc has to be reconfigured to enable host fairness, which leads to the\narray out-of-bounds because the wrapped-around value is retained and\nused as an array index. It seems that syzbot managed to trigger this,\nwhich is quite impressive in its own right.\r\n\r\nThis patch fixes the issue by introducing the same conditional check on\ndecrement as is used on increment.\r\n\r\nThe original bug predates the upstreaming of cake, but the commit listed\nin the Fixes tag touched that code, meaning that this patch won\u0026apos;t apply\nbefore that.(CVE-2024-46828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: clean up our handling of refs == 0 in snapshot delete\r\n\r\nIn reada we BUG_ON(refs == 0), which could be unkind since we aren\u0026apos;t\nholding a lock on the extent leaf and thus could get a transient\nincorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which\ncould happen if we have extent tree corruption.  Change that to return\n-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,\nhowever we return -EIO, which -EUCLEAN is a more appropriate error code.\nFinally in walk_up_proc we have the same BUG_ON(refs == 0), so convert\nthat to proper error handling.  Also adjust the error message so we can\nactually do something with the information.(CVE-2024-46840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/x86/intel: Limit the period on Haswell\r\n\r\nRunning the ltp test cve-2015-3290 concurrently reports the following\nwarnings.\r\n\r\nperfevents: irq loop stuck!\n  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174\n  intel_pmu_handle_irq+0x285/0x370\n  Call Trace:\n   \u0026lt;NMI\u0026gt;\n   ? __warn+0xa4/0x220\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? __report_bug+0x123/0x130\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? __report_bug+0x123/0x130\n   ? intel_pmu_handle_irq+0x285/0x370\n   ? report_bug+0x3e/0xa0\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x50\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? irq_work_claim+0x1e/0x40\n   ? intel_pmu_handle_irq+0x285/0x370\n   perf_event_nmi_handler+0x3d/0x60\n   nmi_handle+0x104/0x330\r\n\r\nThanks to Thomas Gleixner\u0026apos;s analysis, the issue is caused by the low\ninitial period (1) of the frequency estimation algorithm, which triggers\nthe defects of the HW, specifically erratum HSW11 and HSW143. (For the\ndetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)\r\n\r\nThe HSW11 requires a period larger than 100 for the INST_RETIRED.ALL\nevent, but the initial period in the freq mode is 1. The erratum is the\nsame as the BDM11, which has been supported in the kernel. A minimum\nperiod of 128 is enforced as well on HSW.\r\n\r\nHSW143 is regarding that the fixed counter 1 may overcount 32 with the\nHyper-Threading is enabled. However, based on the test, the hardware\nhas more issues than it tells. Besides the fixed counter 1, the message\n\u0026apos;interrupt took too long\u0026apos; can be observed on any counter which was armed\nwith a period \u0026lt; 32 and two events expired in the same NMI. A minimum\nperiod of 32 is enforced for the rest of the events.\nThe recommended workaround code of the HSW143 is not implemented.\nBecause it only addresses the issue for the fixed counter. It brings\nextra overhead through extra MSR writing. No related overcounting issue\nhas been reported so far.(CVE-2024-46848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dpaa: Pad packets to ETH_ZLEN\r\n\r\nWhen sending packets under 60 bytes, up to three bytes of the buffer\nfollowing the data may be leaked. Avoid this by extending all packets to\nETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be\nreproduced by running\r\n\r\n\t$ ping -s 11 destination(CVE-2024-46854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_socket: fix sk refcount leaks\r\n\r\nWe must put \u0026apos;sk\u0026apos; reference before returning.(CVE-2024-46855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: Fix uaf in __timer_delete_sync\r\n\r\nThere are two paths to access mptcp_pm_del_add_timer, result in a race\ncondition:\r\n\r\n     CPU1\t\t\t\tCPU2\n     ====                               ====\n     net_rx_action\n     napi_poll                          netlink_sendmsg\n     __napi_poll                        netlink_unicast\n     process_backlog                    netlink_unicast_kernel\n     __netif_receive_skb                genl_rcv\n     __netif_receive_skb_one_core       netlink_rcv_skb\n     NF_HOOK                            genl_rcv_msg\n     ip_local_deliver_finish            genl_family_rcv_msg\n     ip_protocol_deliver_rcu            genl_family_rcv_msg_doit\n     tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit\n     tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list\n     tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows\n     tcp_data_queue                     remove_anno_list_by_saddr\n     mptcp_incoming_options             mptcp_pm_del_add_timer\n     mptcp_pm_del_add_timer             kfree(entry)\r\n\r\nIn remove_anno_list_by_saddr(running on CPU2), after leaving the critical\nzone protected by \u0026quot;pm.lock\u0026quot;, the entry will be released, which leads to the\noccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).\r\n\r\nKeeping a reference to add_timer inside the lock, and calling\nsk_stop_timer_sync() with this reference, instead of \u0026quot;entry-\u0026gt;add_timer\u0026quot;.\r\n\r\nMove list_del(\u0026amp;entry-\u0026gt;list) to mptcp_pm_del_add_timer and inside the pm lock,\ndo not directly access any members of the entry outside the pm lock, which\ncan avoid similar \u0026quot;entry-\u0026gt;x\u0026quot; uaf.(CVE-2024-46858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: stm32/cryp - call finalize with bh disabled\r\n\r\nThe finalize operation in interrupt mode produce a produces a spinlock\nrecursion warning. The reason is the fact that BH must be disabled\nduring this process.(CVE-2024-47658)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware\r\n\r\nIf the value of max_speed_hz is 0, it may cause a division by zero\nerror in hisi_calc_effective_speed().\nThe value of max_speed_hz is provided by firmware.\nFirmware is generally considered as a trusted domain. However, as\ndivision by zero errors can cause system failure, for defense measure,\nthe value of max_speed is validated here. So 0 is regarded as invalid\nand an error code is returned.(CVE-2024-47664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_xattr_find_entry()\r\n\r\nAdd a paranoia check to make sure it doesn\u0026apos;t stray beyond valid memory\nregion containing ocfs2 xattr entries when scanning for a match.  It will\nprevent out-of-bound access in case of crafted images.(CVE-2024-47670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usbtmc: prevent kernel-usb-infoleak\r\n\r\nThe syzbot reported a kernel-usb-infoleak in usbtmc_write,\nwe need to clear the structure before filling fields.(CVE-2024-47671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: don\u0026apos;t wait for tx queues if firmware is dead\r\n\r\nThere is a WARNING in iwl_trans_wait_tx_queues_empty() (that was\nrecently converted from just a message), that can be hit if we\nwait for TX queues to become empty after firmware died. Clearly,\nwe can\u0026apos;t expect anything from the firmware after it\u0026apos;s declared dead.\r\n\r\nDon\u0026apos;t call iwl_trans_wait_tx_queues_empty() in this case. While it could\nbe a good idea to stop the flow earlier, the flush functions do some\nmaintenance work that is not related to the firmware, so keep that part\nof the code running even when the firmware is not running.\r\n\r\n[edit commit message](CVE-2024-47672)","status":"published","published":"2024-10-18T11:07:44Z","modified":"2026-08-18T01:17:34.647251189Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"ROOT-OS-DEBIAN-11-CVE-2024-42067","title":"CVE-2024-42067 in linux - Patched by Root","description":"Root has patched CVE-2024-42067 in the linux package for Root:Debian:11. Multiple fixed versions available.","status":"published","published":"2026-08-23T09:13:41Z","modified":"2026-08-23T10:16:02.989951617Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:53:29.077857Z"},{"id":"ROOT-OS-DEBIAN-12-CVE-2024-42067","title":"CVE-2024-42067 in linux - Patched by Root","description":"Root has patched CVE-2024-42067 in the linux package for Root:Debian:12. Multiple fixed versions available.","status":"published","published":"2026-10-18T03:18:11Z","modified":"2026-10-18T04:17:39.516791339Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:53:30.70924Z"},{"id":"ROOT-OS-UBUNTU-2204-CVE-2024-42067","title":"CVE-2024-42067 in linux - Patched by Root","description":"Root has patched CVE-2024-42067 in the linux package for Root:Ubuntu:22.04. Multiple fixed versions available.","status":"published","published":"2026-11-06T13:52:25Z","modified":"2026-11-06T14:17:07.851962172Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-06T14:57:21.022388Z"},{"id":"UBUNTU-CVE-2024-42067","description":"In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro() set_memory_rox() can fail, leaving memory unprotected. Check return and bail out when bpf_jit_binary_lock_ro() returns an error.","status":"published","published":"2024-07-29T16:15:00Z","modified":"2026-11-12T17:24:21.202020432Z","cvss":[{"version":"4.0","score":2,"vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"},{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"},{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-12T18:04:02.34559Z"},{"id":"MGASA-2024-0277","title":"Updated kernel, kmod-xtables-addons \u0026 kmod-virtualbox packages fix security vulnerabilities","description":"Upstream kernel version 6.6.43 fix bugs and vulnerabilities.\nThe kmod-virtualbox and kmod-xtables-addons packages have been\nupdated to work with this new kernel.\nFor information about the vulnerabilities see the links.\n","status":"published","published":"2024-08-07T05:49:38Z","modified":"2026-04-16T04:44:39.180015787Z","updated_at":"2026-11-02T15:49:42.684501Z"},{"id":"MGASA-2024-0278","title":"Updated kernel-linus packages fix security vulnerabilities","description":"Vanilla upstream kernel version 6.6.43 fix bugs and vulnerabilities.\nFor information about the vulnerabilities see the links.\n","status":"published","published":"2024-08-07T05:49:38Z","modified":"2026-04-16T04:42:04.810853602Z","updated_at":"2026-11-02T15:49:42.684501Z"},{"id":"USN-7089-1","title":"linux, linux-gcp-6.8, linux-hwe-6.8 vulnerabilities","description":"Chenyuan Yang discovered that the USB Gadget subsystem in the Linux kernel\ndid not properly check for the device to be enabled before writing. A local\nattacker could possibly use this to cause a denial of service. (CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Serial ATA and Parallel ATA drivers;\n  - Null block device driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Cirrus firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - Network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Serial drivers;\n  - VFIO drivers;\n  - VHOST drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system client;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Memory management;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - BPF subsystem;\n  - Core kernel;\n  - Bluetooth subsystem;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - Wireless networking;\n  - AMD SoC Alsa drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - MediaTek ASoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n(CVE-2024-42104, CVE-2024-42084, CVE-2024-42252, CVE-2024-41096,\nCVE-2024-42237, CVE-2024-42140, CVE-2024-42150, CVE-2024-41031,\nCVE-2024-41059, CVE-2024-41062, CVE-2024-41051, CVE-2024-41028,\nCVE-2024-41090, CVE-2024-41092, CVE-2024-43855, CVE-2024-41021,\nCVE-2024-42229, CVE-2024-41056, CVE-2024-41048, CVE-2024-41036,\nCVE-2024-42094, CVE-2024-41089, CVE-2024-41068, CVE-2024-41039,\nCVE-2024-41095, CVE-2024-41069, CVE-2024-42234, CVE-2024-42136,\nCVE-2024-41025, CVE-2024-42157, CVE-2024-42248, CVE-2024-42087,\nCVE-2024-41041, CVE-2024-42230, CVE-2024-42151, CVE-2024-42130,\nCVE-2024-42244, CVE-2024-41079, CVE-2024-42253, CVE-2024-42092,\nCVE-2024-41022, CVE-2024-42137, CVE-2024-42132, CVE-2024-42108,\nCVE-2024-42155, CVE-2024-42127, CVE-2024-41060, CVE-2024-42074,\nCVE-2024-41081, CVE-2024-42066, CVE-2024-42098, CVE-2024-42082,\nCVE-2024-42093, CVE-2024-42245, CVE-2024-41072, CVE-2024-41052,\nCVE-2024-42161, CVE-2024-42096, CVE-2024-42115, CVE-2024-41074,\nCVE-2024-42120, CVE-2024-41046, CVE-2024-42239, CVE-2024-41063,\nCVE-2024-42090, CVE-2024-41023, CVE-2024-42069, CVE-2024-41087,\nCVE-2024-42158, CVE-2024-41067, CVE-2024-41084, CVE-2024-41077,\nCVE-2024-42240, CVE-2024-42145, CVE-2024-42102, CVE-2024-41020,\nCVE-2024-42231, CVE-2024-41053, CVE-2024-42131, CVE-2024-42089,\nCVE-2024-41083, CVE-2024-42247, CVE-2024-42105, CVE-2024-41044,\nCVE-2024-42128, CVE-2024-42271, CVE-2024-41037, CVE-2024-42114,\nCVE-2024-42106, CVE-2024-41076, CVE-2024-42088, CVE-2024-41057,\nCVE-2024-41091, CVE-2024-42152, CVE-2024-41070, CVE-2024-41035,\nCVE-2024-41050, CVE-2024-39487, CVE-2024-42113, CVE-2024-42250,\nCVE-2024-41047, CVE-2024-42149, CVE-2024-42079, CVE-2024-42091,\nCVE-2024-42227, CVE-2024-42095, CVE-2024-42109, CVE-2024-41033,\nCVE-2023-52888, CVE-2024-41061, CVE-2024-42223, CVE-2024-42235,\nCVE-2024-41086, CVE-2024-42133, CVE-2024-41082, CVE-2024-41071,\nCVE-2024-41007, CVE-2023-52887, CVE-2024-39486, CVE-2024-41075,\nCVE-2024-42101, CVE-2024-42077, CVE-2024-41042, CVE-2024-42225,\nCVE-2024-42126, CVE-2024-41094, CVE-2024-41085, CVE-2024-41019,\nCVE-2024-41058, CVE-2024-41066, CVE-2024-42156, CVE-2024-42119,\nCVE-2024-41032, CVE-2024-41088, CVE-2024-42100, CVE-2024-42142,\nCVE-2024-41054, CVE-2024-42103, CVE-2024-42124, CVE-2024-41034,\nCVE-2024-42251, CVE-2024-42153, CVE-2024-41045, CVE-2024-42086,\nCVE-2024-42243, CVE-2024-41055, CVE-2024-41078, CVE-2024-42117,\nCVE-2024-41030, CVE-2024-42068, CVE-2024-42110, CVE-2024-42147,\nCVE-2024-42121, CVE-2024-41080, CVE-2024-41027, CVE-2024-43858,\nCVE-2024-42085, CVE-2024-42111, CVE-2024-42238, CVE-2024-41018,\nCVE-2024-42138, CVE-2024-41038, CVE-2024-42070, CVE-2024-42141,\nCVE-2024-41098, CVE-2024-42118, CVE-2024-41073, CVE-2024-42144,\nCVE-2024-42280, CVE-2024-41049, CVE-2024-42076, CVE-2024-41065,\nCVE-2024-42063, CVE-2024-41064, CVE-2024-41017, CVE-2024-42112,\nCVE-2024-42064, CVE-2024-42135, CVE-2024-42146, CVE-2024-41010,\nCVE-2024-41097, CVE-2024-41012, CVE-2024-42097, CVE-2024-42067,\nCVE-2024-42236, CVE-2024-42080, CVE-2024-42241, CVE-2024-42065,\nCVE-2024-42232, CVE-2024-42246, CVE-2024-41093, CVE-2024-41015,\nCVE-2024-42129, CVE-2024-42073, CVE-2024-41029)\n","status":"published","published":"2024-11-01T13:15:22Z","modified":"2026-10-26T22:33:59.398740884Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7089-2","title":"linux-azure, linux-gcp, linux-ibm vulnerabilities","description":"\nChenyuan Yang discovered that the USB Gadget subsystem in the Linux\nkernel did not properly check for the device to be enabled before\nwriting. A local attacker could possibly use this to cause a denial of\nservice. (CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Serial ATA and Parallel ATA drivers;\n  - Null block device driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Cirrus firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - Network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Serial drivers;\n  - VFIO drivers;\n  - VHOST drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system client;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Memory management;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - BPF subsystem;\n  - Core kernel;\n  - Bluetooth subsystem;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - Wireless networking;\n  - AMD SoC Alsa drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - MediaTek ASoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n(CVE-2024-42104, CVE-2024-42101, CVE-2024-41052, CVE-2024-42157,\nCVE-2024-41020, CVE-2024-41055, CVE-2024-42124, CVE-2023-52888,\nCVE-2024-42079, CVE-2024-43858, CVE-2024-41075, CVE-2024-42073,\nCVE-2024-42113, CVE-2024-42110, CVE-2024-41080, CVE-2024-42097,\nCVE-2024-41046, CVE-2024-42076, CVE-2024-41010, CVE-2024-41018,\nCVE-2024-42115, CVE-2024-41048, CVE-2024-42231, CVE-2024-42241,\nCVE-2024-41034, CVE-2024-42065, CVE-2024-42140, CVE-2024-42094,\nCVE-2024-41029, CVE-2024-42225, CVE-2024-41096, CVE-2024-42088,\nCVE-2024-41087, CVE-2023-52887, CVE-2024-42141, CVE-2024-42135,\nCVE-2024-42247, CVE-2024-39487, CVE-2024-42229, CVE-2024-42147,\nCVE-2024-42252, CVE-2024-41038, CVE-2024-41083, CVE-2024-42091,\nCVE-2024-42156, CVE-2024-42149, CVE-2024-41015, CVE-2024-41047,\nCVE-2024-42129, CVE-2024-42120, CVE-2024-41097, CVE-2024-42243,\nCVE-2024-42084, CVE-2024-42250, CVE-2024-41023, CVE-2024-41028,\nCVE-2024-42108, CVE-2024-41045, CVE-2024-42098, CVE-2024-41064,\nCVE-2024-42087, CVE-2024-42080, CVE-2024-41049, CVE-2024-42271,\nCVE-2024-41037, CVE-2024-42114, CVE-2024-41044, CVE-2024-42126,\nCVE-2024-42119, CVE-2024-42223, CVE-2024-42280, CVE-2024-42112,\nCVE-2024-41019, CVE-2024-42133, CVE-2024-42152, CVE-2024-41074,\nCVE-2024-41042, CVE-2024-41093, CVE-2024-41025, CVE-2024-42253,\nCVE-2024-42136, CVE-2024-42127, CVE-2024-41036, CVE-2024-42237,\nCVE-2024-42111, CVE-2024-41031, CVE-2024-41069, CVE-2024-41084,\nCVE-2024-41076, CVE-2024-41090, CVE-2024-41088, CVE-2024-41070,\nCVE-2024-42118, CVE-2024-42238, CVE-2024-42234, CVE-2024-41089,\nCVE-2024-41095, CVE-2024-41085, CVE-2024-42106, CVE-2024-42155,\nCVE-2024-42146, CVE-2024-42130, CVE-2024-42089, CVE-2024-42132,\nCVE-2024-41091, CVE-2024-42153, CVE-2024-42236, CVE-2024-42085,\nCVE-2024-41065, CVE-2024-41032, CVE-2024-42090, CVE-2024-41030,\nCVE-2024-41017, CVE-2024-42230, CVE-2024-42144, CVE-2024-42137,\nCVE-2024-41082, CVE-2024-41056, CVE-2024-42145, CVE-2024-41041,\nCVE-2024-42240, CVE-2024-41081, CVE-2024-42103, CVE-2024-41053,\nCVE-2024-42070, CVE-2024-42121, CVE-2024-42105, CVE-2024-41022,\nCVE-2024-42151, CVE-2024-42142, CVE-2024-41035, CVE-2024-42232,\nCVE-2024-41058, CVE-2024-42109, CVE-2024-41077, CVE-2024-42095,\nCVE-2024-39486, CVE-2024-42131, CVE-2024-42068, CVE-2024-41073,\nCVE-2024-41079, CVE-2024-42082, CVE-2024-41071, CVE-2024-41066,\nCVE-2024-42102, CVE-2024-43855, CVE-2024-41061, CVE-2024-41072,\nCVE-2024-41059, CVE-2024-41094, CVE-2024-41021, CVE-2024-41098,\nCVE-2024-42158, CVE-2024-41033, CVE-2024-42096, CVE-2024-42251,\nCVE-2024-42077, CVE-2024-42063, CVE-2024-42227, CVE-2024-41007,\nCVE-2024-41057, CVE-2024-41063, CVE-2024-41039, CVE-2024-41067,\nCVE-2024-41062, CVE-2024-42100, CVE-2024-42074, CVE-2024-42064,\nCVE-2024-41092, CVE-2024-42128, CVE-2024-41086, CVE-2024-41054,\nCVE-2024-42239, CVE-2024-41027, CVE-2024-42093, CVE-2024-42244,\nCVE-2024-41050, CVE-2024-41012, CVE-2024-42246, CVE-2024-42117,\nCVE-2024-42069, CVE-2024-42067, CVE-2024-42086, CVE-2024-42066,\nCVE-2024-41060, CVE-2024-42248, CVE-2024-41068, CVE-2024-42161,\nCVE-2024-42092, CVE-2024-42245, CVE-2024-41078, CVE-2024-42235,\nCVE-2024-42150, CVE-2024-41051, CVE-2024-42138)\n","status":"published","published":"2024-11-04T17:30:30Z","modified":"2026-10-26T22:34:00.39355758Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7089-3","title":"linux-aws, linux-aws-6.8, linux-oracle, linux-oracle-6.8 vulnerabilities","description":"\nChenyuan Yang discovered that the USB Gadget subsystem in the Linux\nkernel did not properly check for the device to be enabled before\nwriting. A local attacker could possibly use this to cause a denial of\nservice. (CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Serial ATA and Parallel ATA drivers;\n  - Null block device driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Cirrus firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - Network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Serial drivers;\n  - VFIO drivers;\n  - VHOST drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system client;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Memory management;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - BPF subsystem;\n  - Core kernel;\n  - Bluetooth subsystem;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - Wireless networking;\n  - AMD SoC Alsa drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - MediaTek ASoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n(CVE-2024-42239, CVE-2024-42079, CVE-2024-41080, CVE-2024-42064,\nCVE-2024-42127, CVE-2024-41049, CVE-2024-41086, CVE-2024-42142,\nCVE-2024-42244, CVE-2024-41060, CVE-2024-42131, CVE-2024-42085,\nCVE-2024-42246, CVE-2024-41062, CVE-2024-42115, CVE-2024-42234,\nCVE-2024-42080, CVE-2024-41095, CVE-2024-41063, CVE-2024-42227,\nCVE-2024-41089, CVE-2024-42133, CVE-2024-43858, CVE-2024-42135,\nCVE-2024-42113, CVE-2024-42120, CVE-2024-42149, CVE-2024-42132,\nCVE-2024-41038, CVE-2024-41069, CVE-2024-41090, CVE-2024-41059,\nCVE-2024-41028, CVE-2024-42126, CVE-2024-42121, CVE-2024-42155,\nCVE-2024-42110, CVE-2024-41021, CVE-2024-41044, CVE-2024-42098,\nCVE-2024-42235, CVE-2024-41083, CVE-2024-41065, CVE-2024-42094,\nCVE-2024-42229, CVE-2024-42240, CVE-2024-42225, CVE-2024-42230,\nCVE-2024-41088, CVE-2024-42073, CVE-2024-42145, CVE-2024-42076,\nCVE-2024-42087, CVE-2024-42241, CVE-2024-41019, CVE-2024-41052,\nCVE-2024-42093, CVE-2024-42063, CVE-2024-41039, CVE-2024-42106,\nCVE-2024-42108, CVE-2024-42237, CVE-2024-41048, CVE-2024-41033,\nCVE-2023-52888, CVE-2024-41096, CVE-2024-41032, CVE-2024-41091,\nCVE-2024-42238, CVE-2024-41056, CVE-2024-42091, CVE-2024-42088,\nCVE-2024-41047, CVE-2024-42271, CVE-2024-41064, CVE-2024-42223,\nCVE-2024-42129, CVE-2024-42102, CVE-2024-42146, CVE-2024-42138,\nCVE-2024-41079, CVE-2024-42232, CVE-2024-42112, CVE-2024-39487,\nCVE-2024-42245, CVE-2024-41093, CVE-2024-41066, CVE-2024-43855,\nCVE-2024-41055, CVE-2024-42100, CVE-2024-41053, CVE-2024-42069,\nCVE-2024-42252, CVE-2024-42243, CVE-2024-42124, CVE-2024-41054,\nCVE-2024-42151, CVE-2024-42118, CVE-2024-42251, CVE-2024-42137,\nCVE-2024-41071, CVE-2024-41010, CVE-2024-41087, CVE-2024-41050,\nCVE-2024-42068, CVE-2024-42158, CVE-2024-41075, CVE-2024-42141,\nCVE-2024-42236, CVE-2024-41068, CVE-2024-42157, CVE-2024-42140,\nCVE-2024-41058, CVE-2024-41076, CVE-2024-42097, CVE-2024-41029,\nCVE-2024-41097, CVE-2024-42109, CVE-2024-41051, CVE-2024-41061,\nCVE-2024-42156, CVE-2024-42101, CVE-2024-41031, CVE-2024-41017,\nCVE-2024-42247, CVE-2024-42128, CVE-2024-41085, CVE-2024-41072,\nCVE-2024-42248, CVE-2024-41045, CVE-2024-42104, CVE-2024-42253,\nCVE-2024-42117, CVE-2024-41078, CVE-2024-42130, CVE-2024-42090,\nCVE-2024-42280, CVE-2024-42250, CVE-2024-42231, CVE-2024-41042,\nCVE-2024-42077, CVE-2024-42153, CVE-2024-41015, CVE-2024-41035,\nCVE-2024-41082, CVE-2024-42114, CVE-2024-41007, CVE-2024-41073,\nCVE-2024-42161, CVE-2024-42082, CVE-2024-42150, CVE-2024-42111,\nCVE-2024-42086, CVE-2024-42095, CVE-2024-41025, CVE-2024-41081,\nCVE-2024-42105, CVE-2024-41027, CVE-2024-42089, CVE-2024-39486,\nCVE-2024-41084, CVE-2024-42092, CVE-2024-42152, CVE-2024-41022,\nCVE-2024-41077, CVE-2024-41098, CVE-2024-41023, CVE-2024-42066,\nCVE-2024-41034, CVE-2024-41037, CVE-2024-41046, CVE-2023-52887,\nCVE-2024-42147, CVE-2024-42065, CVE-2024-42096, CVE-2024-41018,\nCVE-2024-42067, CVE-2024-41041, CVE-2024-42103, CVE-2024-42084,\nCVE-2024-42074, CVE-2024-41094, CVE-2024-42119, CVE-2024-41012,\nCVE-2024-41020, CVE-2024-41074, CVE-2024-42144, CVE-2024-41067,\nCVE-2024-42070, CVE-2024-41057, CVE-2024-41036, CVE-2024-42136,\nCVE-2024-41030, CVE-2024-41070, CVE-2024-41092)\n","status":"published","published":"2024-11-07T09:15:50Z","modified":"2026-10-26T22:34:10.691578849Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7089-4","title":"linux-oem-6.8 vulnerabilities","description":"\nChenyuan Yang discovered that the USB Gadget subsystem in the Linux\nkernel did not properly check for the device to be enabled before\nwriting. A local attacker could possibly use this to cause a denial of\nservice. (CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Serial ATA and Parallel ATA drivers;\n  - Null block device driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Cirrus firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - Network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Serial drivers;\n  - VFIO drivers;\n  - VHOST drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system client;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Memory management;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - BPF subsystem;\n  - Core kernel;\n  - Bluetooth subsystem;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - Wireless networking;\n  - AMD SoC Alsa drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - MediaTek ASoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n(CVE-2024-41064, CVE-2024-41087, CVE-2023-52888, CVE-2024-42098,\nCVE-2024-42111, CVE-2024-42076, CVE-2024-42088, CVE-2024-42135,\nCVE-2024-42145, CVE-2024-42142, CVE-2024-41036, CVE-2024-41071,\nCVE-2024-41012, CVE-2024-42091, CVE-2024-42253, CVE-2024-42119,\nCVE-2024-42097, CVE-2024-42243, CVE-2024-39487, CVE-2024-42235,\nCVE-2024-42120, CVE-2024-42149, CVE-2024-41015, CVE-2024-41074,\nCVE-2024-42067, CVE-2024-42090, CVE-2024-42128, CVE-2024-41038,\nCVE-2024-42113, CVE-2024-42102, CVE-2024-42231, CVE-2024-42080,\nCVE-2024-42241, CVE-2024-42106, CVE-2024-42130, CVE-2024-42073,\nCVE-2024-42153, CVE-2024-42156, CVE-2024-42118, CVE-2024-41007,\nCVE-2024-41049, CVE-2024-39486, CVE-2024-42240, CVE-2024-41018,\nCVE-2024-42251, CVE-2024-42280, CVE-2024-42096, CVE-2024-42121,\nCVE-2024-42246, CVE-2024-42092, CVE-2024-41090, CVE-2024-42157,\nCVE-2024-43858, CVE-2024-42150, CVE-2024-42110, CVE-2024-41010,\nCVE-2024-41081, CVE-2024-41061, CVE-2024-41078, CVE-2024-41094,\nCVE-2024-41039, CVE-2024-42114, CVE-2024-42109, CVE-2024-41030,\nCVE-2024-42066, CVE-2024-41035, CVE-2024-42146, CVE-2024-42131,\nCVE-2024-41059, CVE-2024-41067, CVE-2024-42138, CVE-2024-41050,\nCVE-2024-41034, CVE-2024-41077, CVE-2024-41076, CVE-2024-41088,\nCVE-2024-41096, CVE-2024-41073, CVE-2024-41037, CVE-2024-42232,\nCVE-2024-41063, CVE-2024-42117, CVE-2024-42155, CVE-2024-41080,\nCVE-2024-42132, CVE-2024-42084, CVE-2024-42136, CVE-2024-42223,\nCVE-2024-41068, CVE-2024-42225, CVE-2024-42065, CVE-2024-41051,\nCVE-2024-43855, CVE-2024-42238, CVE-2024-42250, CVE-2024-42112,\nCVE-2024-41070, CVE-2023-52887, CVE-2024-42094, CVE-2024-42095,\nCVE-2024-41086, CVE-2024-41020, CVE-2024-41082, CVE-2024-42115,\nCVE-2024-42152, CVE-2024-42239, CVE-2024-42093, CVE-2024-42126,\nCVE-2024-41022, CVE-2024-41017, CVE-2024-41092, CVE-2024-41044,\nCVE-2024-42140, CVE-2024-41029, CVE-2024-41054, CVE-2024-42158,\nCVE-2024-41066, CVE-2024-42244, CVE-2024-42070, CVE-2024-41025,\nCVE-2024-42229, CVE-2024-42085, CVE-2024-41084, CVE-2024-41060,\nCVE-2024-41062, CVE-2024-42105, CVE-2024-42124, CVE-2024-41045,\nCVE-2024-42227, CVE-2024-41047, CVE-2024-41042, CVE-2024-42100,\nCVE-2024-42247, CVE-2024-41041, CVE-2024-42087, CVE-2024-42252,\nCVE-2024-41058, CVE-2024-42063, CVE-2024-42271, CVE-2024-41027,\nCVE-2024-42079, CVE-2024-42104, CVE-2024-41098, CVE-2024-41033,\nCVE-2024-41072, CVE-2024-41031, CVE-2024-42089, CVE-2024-41032,\nCVE-2024-42127, CVE-2024-41093, CVE-2024-42082, CVE-2024-41023,\nCVE-2024-41075, CVE-2024-42151, CVE-2024-42141, CVE-2024-42108,\nCVE-2024-42068, CVE-2024-41085, CVE-2024-42103, CVE-2024-41057,\nCVE-2024-42064, CVE-2024-42161, CVE-2024-41052, CVE-2024-41053,\nCVE-2024-42069, CVE-2024-41021, CVE-2024-42147, CVE-2024-41065,\nCVE-2024-41091, CVE-2024-41079, CVE-2024-42086, CVE-2024-42234,\nCVE-2024-41055, CVE-2024-41083, CVE-2024-42101, CVE-2024-42230,\nCVE-2024-41095, CVE-2024-41019, CVE-2024-42245, CVE-2024-42129,\nCVE-2024-42144, CVE-2024-42236, CVE-2024-41028, CVE-2024-42077,\nCVE-2024-42248, CVE-2024-41046, CVE-2024-42133, CVE-2024-42074,\nCVE-2024-41089, CVE-2024-42237, CVE-2024-41056, CVE-2024-41048,\nCVE-2024-42137, CVE-2024-41069, CVE-2024-41097)\n","status":"published","published":"2024-11-13T12:05:57Z","modified":"2026-10-26T22:33:54.911543556Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7089-5","title":"linux-raspi vulnerabilities","description":"Chenyuan Yang discovered that the USB Gadget subsystem in the Linux\nkernel did not properly check for the device to be enabled before\nwriting. A local attacker could possibly use this to cause a denial of\nservice. (CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Serial ATA and Parallel ATA drivers;\n  - Null block device driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Cirrus firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - Network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Serial drivers;\n  - VFIO drivers;\n  - VHOST drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system client;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Memory management;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - BPF subsystem;\n  - Core kernel;\n  - Bluetooth subsystem;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - Wireless networking;\n  - AMD SoC Alsa drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - MediaTek ASoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n(CVE-2024-42223, CVE-2024-42244, CVE-2024-42105, CVE-2024-42100,\nCVE-2024-42235, CVE-2024-41007, CVE-2024-41047, CVE-2024-42088,\nCVE-2024-42079, CVE-2024-41053, CVE-2024-41094, CVE-2024-42227,\nCVE-2024-42253, CVE-2024-42150, CVE-2024-41049, CVE-2024-42096,\nCVE-2024-42093, CVE-2024-41079, CVE-2024-41037, CVE-2024-42129,\nCVE-2024-41031, CVE-2024-39486, CVE-2024-41065, CVE-2024-42101,\nCVE-2024-41082, CVE-2024-42135, CVE-2024-42236, CVE-2024-41078,\nCVE-2024-42098, CVE-2024-41056, CVE-2024-41096, CVE-2024-41074,\nCVE-2024-42246, CVE-2024-42137, CVE-2024-42232, CVE-2024-42121,\nCVE-2024-41093, CVE-2024-41076, CVE-2024-42157, CVE-2024-41062,\nCVE-2024-42104, CVE-2024-42085, CVE-2024-41092, CVE-2024-41034,\nCVE-2024-41036, CVE-2024-41072, CVE-2024-41012, CVE-2024-39487,\nCVE-2024-42124, CVE-2024-42065, CVE-2024-41061, CVE-2024-41064,\nCVE-2024-41091, CVE-2024-42119, CVE-2024-41088, CVE-2024-42089,\nCVE-2024-41048, CVE-2024-41032, CVE-2024-41020, CVE-2024-42066,\nCVE-2024-42068, CVE-2024-42238, CVE-2024-41069, CVE-2024-41044,\nCVE-2024-41025, CVE-2024-42161, CVE-2023-52887, CVE-2024-42127,\nCVE-2024-42239, CVE-2024-42149, CVE-2024-42091, CVE-2024-42097,\nCVE-2024-41054, CVE-2024-41041, CVE-2024-42131, CVE-2024-41089,\nCVE-2024-41018, CVE-2024-42067, CVE-2024-41039, CVE-2024-42128,\nCVE-2024-42248, CVE-2024-41090, CVE-2024-42073, CVE-2024-43858,\nCVE-2024-42225, CVE-2024-42077, CVE-2024-42247, CVE-2024-42109,\nCVE-2024-41045, CVE-2024-41019, CVE-2024-42231, CVE-2024-41017,\nCVE-2024-42145, CVE-2024-41046, CVE-2024-42063, CVE-2024-41087,\nCVE-2024-41033, CVE-2024-41021, CVE-2024-42241, CVE-2024-42229,\nCVE-2024-41015, CVE-2024-42087, CVE-2024-42133, CVE-2024-41073,\nCVE-2024-42070, CVE-2024-41067, CVE-2024-41077, CVE-2024-42102,\nCVE-2024-42158, CVE-2024-42126, CVE-2024-41042, CVE-2024-41055,\nCVE-2024-42092, CVE-2024-42114, CVE-2024-41059, CVE-2024-41058,\nCVE-2024-41071, CVE-2024-42144, CVE-2024-42146, CVE-2024-41084,\nCVE-2024-42155, CVE-2024-42245, CVE-2024-42156, CVE-2024-41050,\nCVE-2024-42141, CVE-2024-42095, CVE-2024-41097, CVE-2024-42103,\nCVE-2024-42152, CVE-2024-42140, CVE-2024-41023, CVE-2024-41083,\nCVE-2024-42138, CVE-2024-42271, CVE-2024-42252, CVE-2024-42237,\nCVE-2024-42132, CVE-2024-41098, CVE-2024-42086, CVE-2024-41063,\nCVE-2024-42153, CVE-2024-41070, CVE-2024-42115, CVE-2024-42111,\nCVE-2024-42142, CVE-2024-42069, CVE-2024-41027, CVE-2024-42130,\nCVE-2024-42090, CVE-2024-42251, CVE-2024-42118, CVE-2024-41060,\nCVE-2024-41029, CVE-2024-41095, CVE-2024-41038, CVE-2024-42243,\nCVE-2024-42112, CVE-2024-41035, CVE-2024-42240, CVE-2024-41066,\nCVE-2024-41085, CVE-2024-42082, CVE-2024-42117, CVE-2024-42250,\nCVE-2024-41080, CVE-2024-42147, CVE-2024-41081, CVE-2024-42113,\nCVE-2023-52888, CVE-2024-42136, CVE-2024-41057, CVE-2024-41086,\nCVE-2024-42064, CVE-2024-42234, CVE-2024-42076, CVE-2024-42084,\nCVE-2024-42094, CVE-2024-42230, CVE-2024-41068, CVE-2024-43855,\nCVE-2024-42080, CVE-2024-41052, CVE-2024-41051, CVE-2024-42074,\nCVE-2024-41010, CVE-2024-41028, CVE-2024-41030, CVE-2024-41022,\nCVE-2024-42120, CVE-2024-42108, CVE-2024-41075, CVE-2024-42106,\nCVE-2024-42280, CVE-2024-42110, CVE-2024-42151)\n","status":"published","published":"2024-11-14T16:55:06Z","modified":"2026-10-26T22:33:56.031381167Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7089-6","title":"linux-gke vulnerabilities","description":"\nChenyuan Yang discovered that the USB Gadget subsystem in the Linux\nkernel did not properly check for the device to be enabled before\nwriting. A local attacker could possibly use this to cause a denial of\nservice. (CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Serial ATA and Parallel ATA drivers;\n  - Null block device driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Cirrus firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - Network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Serial drivers;\n  - VFIO drivers;\n  - VHOST drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system client;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Memory management;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - BPF subsystem;\n  - Core kernel;\n  - Bluetooth subsystem;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - Wireless networking;\n  - AMD SoC Alsa drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - MediaTek ASoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n(CVE-2024-41062, CVE-2024-41029, CVE-2024-42142, CVE-2024-41070,\nCVE-2024-41066, CVE-2024-42150, CVE-2024-42120, CVE-2023-52888,\nCVE-2024-42141, CVE-2024-41032, CVE-2024-42245, CVE-2024-41053,\nCVE-2024-42247, CVE-2024-42161, CVE-2024-42094, CVE-2024-41072,\nCVE-2024-42076, CVE-2024-42091, CVE-2024-42103, CVE-2024-41007,\nCVE-2024-42064, CVE-2024-41075, CVE-2024-42157, CVE-2024-42069,\nCVE-2024-41045, CVE-2024-42068, CVE-2024-42090, CVE-2024-41071,\nCVE-2024-42082, CVE-2024-42146, CVE-2024-41018, CVE-2024-42238,\nCVE-2024-41079, CVE-2024-42241, CVE-2024-42067, CVE-2024-42132,\nCVE-2024-42121, CVE-2024-41025, CVE-2024-42231, CVE-2024-42225,\nCVE-2024-41080, CVE-2024-41086, CVE-2024-41012, CVE-2024-42234,\nCVE-2024-41088, CVE-2024-42129, CVE-2024-42158, CVE-2024-41078,\nCVE-2024-41038, CVE-2024-41055, CVE-2024-42106, CVE-2024-42227,\nCVE-2024-42102, CVE-2024-41082, CVE-2024-42108, CVE-2024-41085,\nCVE-2024-41020, CVE-2024-41054, CVE-2024-42085, CVE-2024-42140,\nCVE-2024-42089, CVE-2024-41047, CVE-2024-42092, CVE-2024-41044,\nCVE-2024-42246, CVE-2024-41035, CVE-2024-42250, CVE-2024-42070,\nCVE-2024-41039, CVE-2024-41061, CVE-2024-42147, CVE-2024-42104,\nCVE-2024-41090, CVE-2024-41096, CVE-2024-41063, CVE-2024-41084,\nCVE-2024-41059, CVE-2024-41097, CVE-2024-41089, CVE-2024-42093,\nCVE-2024-42126, CVE-2024-42135, CVE-2024-42128, CVE-2024-42098,\nCVE-2024-42105, CVE-2024-42124, CVE-2024-42101, CVE-2024-41091,\nCVE-2024-42127, CVE-2024-41077, CVE-2024-42111, CVE-2024-41037,\nCVE-2024-42136, CVE-2024-41083, CVE-2024-42243, CVE-2024-41033,\nCVE-2024-41046, CVE-2024-42230, CVE-2024-42080, CVE-2024-42096,\nCVE-2024-42100, CVE-2024-42236, CVE-2024-41022, CVE-2024-42086,\nCVE-2024-42251, CVE-2024-41015, CVE-2024-41027, CVE-2024-42155,\nCVE-2024-42117, CVE-2024-41036, CVE-2024-42133, CVE-2024-41010,\nCVE-2024-42151, CVE-2024-42118, CVE-2024-39486, CVE-2024-42066,\nCVE-2024-42131, CVE-2024-42223, CVE-2024-41081, CVE-2024-42244,\nCVE-2024-41073, CVE-2024-42114, CVE-2024-42252, CVE-2024-42248,\nCVE-2024-42110, CVE-2024-41051, CVE-2023-52887, CVE-2024-42156,\nCVE-2024-41074, CVE-2024-41017, CVE-2024-42079, CVE-2024-41034,\nCVE-2024-41028, CVE-2024-42109, CVE-2024-42235, CVE-2024-41058,\nCVE-2024-42232, CVE-2024-42084, CVE-2024-41076, CVE-2024-41030,\nCVE-2024-41023, CVE-2024-42271, CVE-2024-41050, CVE-2024-41042,\nCVE-2024-41031, CVE-2024-42112, CVE-2024-41092, CVE-2024-42253,\nCVE-2024-42152, CVE-2024-41049, CVE-2024-42237, CVE-2024-41095,\nCVE-2024-42280, CVE-2024-42153, CVE-2024-42115, CVE-2024-42130,\nCVE-2024-41064, CVE-2024-42077, CVE-2024-41067, CVE-2024-42137,\nCVE-2024-41019, CVE-2024-42240, CVE-2024-41093, CVE-2024-41048,\nCVE-2024-42063, CVE-2024-42113, CVE-2024-42145, CVE-2024-42073,\nCVE-2024-43858, CVE-2024-42088, CVE-2024-41069, CVE-2024-41068,\nCVE-2024-42138, CVE-2024-41065, CVE-2024-42087, CVE-2024-42239,\nCVE-2024-42149, CVE-2024-41021, CVE-2024-42065, CVE-2024-39487,\nCVE-2024-41052, CVE-2024-42095, CVE-2024-42074, CVE-2024-42097,\nCVE-2024-41098, CVE-2024-41057, CVE-2024-41060, CVE-2024-42119,\nCVE-2024-42229, CVE-2024-43855, CVE-2024-41056, CVE-2024-41041,\nCVE-2024-42144, CVE-2024-41087, CVE-2024-41094)\n","status":"published","published":"2024-11-15T10:36:16Z","modified":"2026-10-26T22:34:10.328493163Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7089-7","title":"linux-lowlatency, linux-lowlatency-hwe-6.8 vulnerabilities","description":"Chenyuan Yang discovered that the USB Gadget subsystem in the Linux\nkernel did not properly check for the device to be enabled before\nwriting. A local attacker could possibly use this to cause a denial of\nservice. (CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Serial ATA and Parallel ATA drivers;\n  - Null block device driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Cirrus firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - Network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Serial drivers;\n  - VFIO drivers;\n  - VHOST drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system client;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Memory management;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - BPF subsystem;\n  - Core kernel;\n  - Bluetooth subsystem;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - Wireless networking;\n  - AMD SoC Alsa drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - MediaTek ASoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n(CVE-2024-42104, CVE-2024-42084, CVE-2024-42252, CVE-2024-41096,\nCVE-2024-42237, CVE-2024-42140, CVE-2024-42150, CVE-2024-41031,\nCVE-2024-41059, CVE-2024-41062, CVE-2024-41051, CVE-2024-41028,\nCVE-2024-41090, CVE-2024-41092, CVE-2024-43855, CVE-2024-41021,\nCVE-2024-42229, CVE-2024-41056, CVE-2024-41048, CVE-2024-41036,\nCVE-2024-42094, CVE-2024-41089, CVE-2024-41068, CVE-2024-41039,\nCVE-2024-41095, CVE-2024-41069, CVE-2024-42234, CVE-2024-42136,\nCVE-2024-41025, CVE-2024-42157, CVE-2024-42248, CVE-2024-42087,\nCVE-2024-41041, CVE-2024-42230, CVE-2024-42151, CVE-2024-42130,\nCVE-2024-42244, CVE-2024-41079, CVE-2024-42253, CVE-2024-42092,\nCVE-2024-41022, CVE-2024-42137, CVE-2024-42132, CVE-2024-42108,\nCVE-2024-42155, CVE-2024-42127, CVE-2024-41060, CVE-2024-42074,\nCVE-2024-41081, CVE-2024-42066, CVE-2024-42098, CVE-2024-42082,\nCVE-2024-42093, CVE-2024-42245, CVE-2024-41072, CVE-2024-41052,\nCVE-2024-42161, CVE-2024-42096, CVE-2024-42115, CVE-2024-41074,\nCVE-2024-42120, CVE-2024-41046, CVE-2024-42239, CVE-2024-41063,\nCVE-2024-42090, CVE-2024-41023, CVE-2024-42069, CVE-2024-41087,\nCVE-2024-42158, CVE-2024-41067, CVE-2024-41084, CVE-2024-41077,\nCVE-2024-42240, CVE-2024-42145, CVE-2024-42102, CVE-2024-41020,\nCVE-2024-42231, CVE-2024-41053, CVE-2024-42131, CVE-2024-42089,\nCVE-2024-41083, CVE-2024-42247, CVE-2024-42105, CVE-2024-41044,\nCVE-2024-42128, CVE-2024-42271, CVE-2024-41037, CVE-2024-42114,\nCVE-2024-42106, CVE-2024-41076, CVE-2024-42088, CVE-2024-41057,\nCVE-2024-41091, CVE-2024-42152, CVE-2024-41070, CVE-2024-41035,\nCVE-2024-41050, CVE-2024-39487, CVE-2024-42113, CVE-2024-42250,\nCVE-2024-41047, CVE-2024-42149, CVE-2024-42079, CVE-2024-42091,\nCVE-2024-42227, CVE-2024-42095, CVE-2024-42109, CVE-2024-41033,\nCVE-2023-52888, CVE-2024-41061, CVE-2024-42223, CVE-2024-42235,\nCVE-2024-41086, CVE-2024-42133, CVE-2024-41082, CVE-2024-41071,\nCVE-2024-41007, CVE-2023-52887, CVE-2024-39486, CVE-2024-41075,\nCVE-2024-42101, CVE-2024-42077, CVE-2024-41042, CVE-2024-42225,\nCVE-2024-42126, CVE-2024-41094, CVE-2024-41085, CVE-2024-41019,\nCVE-2024-41058, CVE-2024-41066, CVE-2024-42156, CVE-2024-42119,\nCVE-2024-41032, CVE-2024-41088, CVE-2024-42100, CVE-2024-42142,\nCVE-2024-41054, CVE-2024-42103, CVE-2024-42124, CVE-2024-41034,\nCVE-2024-42251, CVE-2024-42153, CVE-2024-41045, CVE-2024-42086,\nCVE-2024-42243, CVE-2024-41055, CVE-2024-41078, CVE-2024-42117,\nCVE-2024-41030, CVE-2024-42068, CVE-2024-42110, CVE-2024-42147,\nCVE-2024-42121, CVE-2024-41080, CVE-2024-41027, CVE-2024-43858,\nCVE-2024-42085, CVE-2024-42111, CVE-2024-42238, CVE-2024-41018,\nCVE-2024-42138, CVE-2024-41038, CVE-2024-42070, CVE-2024-42141,\nCVE-2024-41098, CVE-2024-42118, CVE-2024-41073, CVE-2024-42144,\nCVE-2024-42280, CVE-2024-41049, CVE-2024-42076, CVE-2024-41065,\nCVE-2024-42063, CVE-2024-41064, CVE-2024-41017, CVE-2024-42112,\nCVE-2024-42064, CVE-2024-42135, CVE-2024-42146, CVE-2024-41010,\nCVE-2024-41097, CVE-2024-41012, CVE-2024-42097, CVE-2024-42067,\nCVE-2024-42236, CVE-2024-42080, CVE-2024-42241, CVE-2024-42065,\nCVE-2024-42232, CVE-2024-42246, CVE-2024-41093, CVE-2024-41015,\nCVE-2024-42129, CVE-2024-42073, CVE-2024-41029)\n","status":"published","published":"2024-11-19T22:35:31Z","modified":"2026-10-26T22:34:04.239512543Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7090-1","title":"linux-azure-6.8 vulnerabilities","description":"\nChenyuan Yang discovered that the USB Gadget subsystem in the Linux\nkernel did not properly check for the device to be enabled before\nwriting. A local attacker could possibly use this to cause a denial of\nservice. (CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Serial ATA and Parallel ATA drivers;\n  - Null block device driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Cirrus firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - Network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Serial drivers;\n  - VFIO drivers;\n  - VHOST drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system client;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Memory management;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - BPF subsystem;\n  - Core kernel;\n  - Bluetooth subsystem;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - Wireless networking;\n  - AMD SoC Alsa drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - MediaTek ASoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n(CVE-2024-42064, CVE-2024-43858, CVE-2024-42251, CVE-2024-42113,\nCVE-2024-41020, CVE-2024-41093, CVE-2024-45016, CVE-2024-42150,\nCVE-2024-42069, CVE-2024-42157, CVE-2024-42126, CVE-2024-42144,\nCVE-2024-42093, CVE-2024-41035, CVE-2024-41032, CVE-2024-41077,\nCVE-2024-42097, CVE-2024-41071, CVE-2024-42227, CVE-2024-42253,\nCVE-2024-42237, CVE-2024-41060, CVE-2024-42080, CVE-2024-42068,\nCVE-2024-41058, CVE-2024-42140, CVE-2024-42231, CVE-2024-42127,\nCVE-2024-42243, CVE-2023-52887, CVE-2024-39486, CVE-2024-41063,\nCVE-2024-42128, CVE-2024-42074, CVE-2024-41028, CVE-2024-42110,\nCVE-2024-45001, CVE-2024-41090, CVE-2024-41084, CVE-2024-41088,\nCVE-2024-42118, CVE-2024-41094, CVE-2024-41091, CVE-2024-41007,\nCVE-2024-42280, CVE-2024-41044, CVE-2024-41012, CVE-2024-42063,\nCVE-2024-41078, CVE-2024-42082, CVE-2024-41055, CVE-2024-41031,\nCVE-2024-42142, CVE-2024-41083, CVE-2024-42145, CVE-2024-41039,\nCVE-2024-41019, CVE-2024-42149, CVE-2024-42248, CVE-2024-42111,\nCVE-2024-41074, CVE-2024-42096, CVE-2024-42100, CVE-2024-41010,\nCVE-2024-43855, CVE-2024-42136, CVE-2024-41054, CVE-2024-41053,\nCVE-2024-41061, CVE-2024-42104, CVE-2024-41025, CVE-2024-42129,\nCVE-2024-41086, CVE-2024-42133, CVE-2024-42115, CVE-2024-42158,\nCVE-2024-42091, CVE-2024-42088, CVE-2024-42161, CVE-2024-42236,\nCVE-2024-41065, CVE-2024-41062, CVE-2024-42153, CVE-2024-41030,\nCVE-2024-41079, CVE-2023-52888, CVE-2024-42223, CVE-2024-42119,\nCVE-2024-42238, CVE-2024-41052, CVE-2024-41064, CVE-2024-42138,\nCVE-2024-41081, CVE-2024-41034, CVE-2024-42147, CVE-2024-41095,\nCVE-2024-42132, CVE-2024-42137, CVE-2024-42106, CVE-2024-41041,\nCVE-2024-41073, CVE-2024-41033, CVE-2024-41075, CVE-2024-42112,\nCVE-2024-41070, CVE-2024-42234, CVE-2024-41027, CVE-2024-42105,\nCVE-2024-41089, CVE-2024-41098, CVE-2024-42152, CVE-2024-42101,\nCVE-2024-41050, CVE-2024-41069, CVE-2024-42120, CVE-2024-42130,\nCVE-2024-42084, CVE-2024-41066, CVE-2024-42108, CVE-2024-42087,\nCVE-2024-41067, CVE-2024-41023, CVE-2024-41046, CVE-2024-42079,\nCVE-2024-42065, CVE-2024-42098, CVE-2024-42070, CVE-2024-41076,\nCVE-2024-41082, CVE-2024-41096, CVE-2024-42235, CVE-2024-42085,\nCVE-2024-42246, CVE-2024-41049, CVE-2024-42076, CVE-2024-41048,\nCVE-2024-41038, CVE-2024-42241, CVE-2024-41092, CVE-2024-42114,\nCVE-2024-41036, CVE-2024-41047, CVE-2024-41029, CVE-2024-42092,\nCVE-2024-41068, CVE-2024-42067, CVE-2024-42094, CVE-2024-42245,\nCVE-2024-41051, CVE-2024-42250, CVE-2024-42151, CVE-2024-41059,\nCVE-2024-41056, CVE-2024-42095, CVE-2024-42131, CVE-2024-42271,\nCVE-2024-42066, CVE-2024-42240, CVE-2024-41017, CVE-2024-42141,\nCVE-2024-41072, CVE-2024-42229, CVE-2024-42239, CVE-2024-42073,\nCVE-2024-42124, CVE-2024-41080, CVE-2024-42146, CVE-2024-41018,\nCVE-2024-41021, CVE-2024-39487, CVE-2024-42086, CVE-2024-42109,\nCVE-2024-41045, CVE-2024-41037, CVE-2024-41097, CVE-2024-42225,\nCVE-2024-42102, CVE-2024-42117, CVE-2024-42077, CVE-2024-42230,\nCVE-2024-41087, CVE-2024-42089, CVE-2024-42252, CVE-2024-42247,\nCVE-2024-41057, CVE-2024-42121, CVE-2024-42232, CVE-2024-42090,\nCVE-2024-41042, CVE-2024-42244, CVE-2024-42156, CVE-2024-42135,\nCVE-2024-42155, CVE-2024-42103, CVE-2024-41015, CVE-2024-41022,\nCVE-2024-41085)\n","status":"published","published":"2024-11-01T13:48:18Z","modified":"2026-10-29T20:02:33.244524175Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7095-1","title":"linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency vulnerabilities","description":"\nChenyuan Yang discovered that the USB Gadget subsystem in the Linux\nkernel did not properly check for the device to be enabled before\nwriting. A local attacker could possibly use this to cause a denial of\nservice. (CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Serial ATA and Parallel ATA drivers;\n  - Null block device driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Cirrus firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - Network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Serial drivers;\n  - VFIO drivers;\n  - VHOST drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system client;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Memory management;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - BPF subsystem;\n  - Core kernel;\n  - Bluetooth subsystem;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - Wireless networking;\n  - AMD SoC Alsa drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - MediaTek ASoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n(CVE-2024-42271, CVE-2024-42068, CVE-2024-42086, CVE-2024-42132,\nCVE-2024-42074, CVE-2024-41017, CVE-2024-42090, CVE-2024-42280,\nCVE-2024-41030, CVE-2024-41037, CVE-2024-42248, CVE-2024-42084,\nCVE-2024-41057, CVE-2024-42252, CVE-2024-41055, CVE-2024-42158,\nCVE-2024-42097, CVE-2024-42101, CVE-2024-42095, CVE-2024-41084,\nCVE-2024-41051, CVE-2024-41032, CVE-2024-41046, CVE-2024-42231,\nCVE-2024-42133, CVE-2024-42089, CVE-2024-41062, CVE-2024-41033,\nCVE-2024-41012, CVE-2024-41077, CVE-2024-41064, CVE-2024-41082,\nCVE-2024-41090, CVE-2024-42065, CVE-2024-41096, CVE-2024-42119,\nCVE-2024-41054, CVE-2024-42064, CVE-2024-42253, CVE-2024-42237,\nCVE-2024-42120, CVE-2024-41066, CVE-2024-41083, CVE-2024-42129,\nCVE-2024-41085, CVE-2024-41058, CVE-2024-42146, CVE-2024-42156,\nCVE-2024-42076, CVE-2024-42149, CVE-2024-42069, CVE-2024-41039,\nCVE-2024-42110, CVE-2024-42150, CVE-2024-41015, CVE-2024-39486,\nCVE-2024-42144, CVE-2024-42131, CVE-2024-42087, CVE-2024-42091,\nCVE-2024-42236, CVE-2024-42088, CVE-2024-42112, CVE-2024-42142,\nCVE-2024-42082, CVE-2024-42111, CVE-2024-41028, CVE-2024-45001,\nCVE-2024-42077, CVE-2024-42102, CVE-2024-42239, CVE-2024-42140,\nCVE-2024-41091, CVE-2024-41050, CVE-2024-41034, CVE-2024-43858,\nCVE-2024-42145, CVE-2024-42227, CVE-2024-41029, CVE-2024-42230,\nCVE-2024-42096, CVE-2024-42238, CVE-2024-41027, CVE-2024-42063,\nCVE-2024-41023, CVE-2024-41041, CVE-2024-41038, CVE-2024-41073,\nCVE-2024-41067, CVE-2024-41025, CVE-2024-42152, CVE-2024-42247,\nCVE-2024-41065, CVE-2024-42121, CVE-2024-42157, CVE-2024-42080,\nCVE-2024-41076, CVE-2024-41059, CVE-2024-42108, CVE-2024-42251,\nCVE-2024-42093, CVE-2024-42130, CVE-2024-42126, CVE-2024-42079,\nCVE-2024-42246, CVE-2024-41081, CVE-2024-42092, CVE-2024-43855,\nCVE-2024-42235, CVE-2024-42118, CVE-2024-42067, CVE-2024-41047,\nCVE-2024-42155, CVE-2024-41010, CVE-2024-41061, CVE-2024-41007,\nCVE-2024-42245, CVE-2024-42106, CVE-2024-42066, CVE-2024-41078,\nCVE-2024-42113, CVE-2024-41087, CVE-2024-41092, CVE-2024-42234,\nCVE-2024-42124, CVE-2024-42100, CVE-2024-42128, CVE-2024-41072,\nCVE-2024-41022, CVE-2024-41049, CVE-2024-42229, CVE-2024-42225,\nCVE-2024-41052, CVE-2024-42151, CVE-2024-41094, CVE-2024-41098,\nCVE-2024-41035, CVE-2024-41042, CVE-2024-42114, CVE-2024-42250,\nCVE-2024-41095, CVE-2024-42138, CVE-2024-42241, CVE-2024-42103,\nCVE-2024-42094, CVE-2024-41045, CVE-2024-41075, CVE-2024-42073,\nCVE-2024-42153, CVE-2024-41048, CVE-2024-42085, CVE-2024-41074,\nCVE-2024-42244, CVE-2024-41018, CVE-2024-41079, CVE-2024-42127,\nCVE-2023-52887, CVE-2023-52888, CVE-2024-41071, CVE-2024-41020,\nCVE-2024-41036, CVE-2024-42117, CVE-2024-41068, CVE-2024-41056,\nCVE-2024-39487, CVE-2024-42243, CVE-2024-41019, CVE-2024-41070,\nCVE-2024-41044, CVE-2024-41060, CVE-2024-41088, CVE-2024-41021,\nCVE-2024-41053, CVE-2024-42137, CVE-2024-41086, CVE-2024-42104,\nCVE-2024-42109, CVE-2024-42105, CVE-2024-42136, CVE-2024-41080,\nCVE-2024-42098, CVE-2024-41093, CVE-2024-41063, CVE-2024-42161,\nCVE-2024-42147, CVE-2024-42223, CVE-2024-41097, CVE-2024-41069,\nCVE-2024-42240, CVE-2024-42135, CVE-2024-42070, CVE-2024-41089,\nCVE-2024-42141, CVE-2024-42115, CVE-2024-41031, CVE-2024-42232)\n","status":"published","published":"2024-11-07T09:49:52Z","modified":"2026-10-29T20:02:37.125807872Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7156-1","title":"linux-gkeop vulnerabilities","description":"\nChenyuan Yang discovered that the USB Gadget subsystem in the Linux kernel\ndid not properly check for the device to be enabled before writing. A local\nattacker could possibly use this to cause a denial of service.\n(CVE-2024-25741)\n\nSeveral security issues were discovered in the Linux kernel.\nAn attacker could possibly use these to compromise the system.\nThis update corrects flaws in the following subsystems:\n  - ARM32 architecture;\n  - ARM64 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - User-Mode Linux (UML);\n  - x86 architecture;\n  - Block layer subsystem;\n  - Cryptographic API;\n  - Android drivers;\n  - Serial ATA and Parallel ATA drivers;\n  - ATM drivers;\n  - Drivers core;\n  - Null block device driver;\n  - Ublk userspace block driver;\n  - Bluetooth drivers;\n  - Cdrom driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Buffer Sharing and Synchronization framework;\n  - DMA engine subsystem;\n  - Cirrus firmware drivers;\n  - Qualcomm firmware drivers;\n  - GPIO subsystem;\n  - GPU drivers;\n  - HID subsystem;\n  - Hardware monitoring drivers;\n  - I2C subsystem;\n  - I3C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Input Device (Miscellaneous) drivers;\n  - IOMMU subsystem;\n  - IRQ chip drivers;\n  - ISDN/mISDN subsystem;\n  - LED subsystem;\n  - Mailbox framework;\n  - Multiple devices driver;\n  - Media drivers;\n  - Fastrpc Driver;\n  - VMware VMCI Driver;\n  - MMC subsystem;\n  - Ethernet bonding driver;\n  - Network drivers;\n  - Mellanox network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - Near Field Communication (NFC) drivers;\n  - NVME drivers;\n  - NVMEM (Non Volatile Memory) drivers;\n  - Device tree and open firmware driver;\n  - Parport drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - Power supply drivers;\n  - Remote Processor subsystem;\n  - S/390 drivers;\n  - SCSI subsystem;\n  - QCOM SoC drivers;\n  - SPI subsystem;\n  - Direct Digital Synthesis drivers;\n  - Thermal drivers;\n  - Thunderbolt and USB4 drivers;\n  - TTY drivers;\n  - UFS subsystem;\n  - Userspace I/O drivers;\n  - USB DSL drivers;\n  - USB core drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Host Controller drivers;\n  - USB Serial drivers;\n  - USB Type-C Connector System Software Interface driver;\n  - USB over IP driver;\n  - VFIO drivers;\n  - Virtio Host (VHOST) subsystem;\n  - Framebuffer layer;\n  - Xen hypervisor drivers;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - Ext4 file system;\n  - F2FS file system;\n  - GFS2 file system;\n  - JFFS2 file system;\n  - JFS file system;\n  - Network file systems library;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - File system notification infrastructure;\n  - NTFS3 file system;\n  - Proc file system;\n  - SMB network file system;\n  - Tracing file system;\n  - Bitmap API;\n  - BPF subsystem;\n  - Syscall compatibility layer;\n  - Memory Management;\n  - Memory management;\n  - Objagg library;\n  - Perf events;\n  - Syscall interfaces;\n  - Virtio network driver;\n  - VMware vSockets driver;\n  - KCM (Kernel Connection Multiplexor) sockets driver;\n  - Netfilter;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - Control group (cgroup);\n  - DMA mapping infrastructure;\n  - Locking primitives;\n  - Padata parallel execution mechanism;\n  - Scheduler infrastructure;\n  - Closures library;\n  - Radix Tree data structure library;\n  - Kernel userspace event delivery library;\n  - KUnit for arithmetic overflow checks;\n  - Bluetooth subsystem;\n  - Ethernet bridge;\n  - CAN network layer;\n  - Ceph Core library;\n  - Networking core;\n  - Ethtool driver;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Network traffic control;\n  - SCTP protocol;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - Wireless networking;\n  - AppArmor security module;\n  - Landlock security;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - FireWire sound drivers;\n  - AMD SoC Alsa drivers;\n  - Texas InstrumentS Audio (ASoC/HDA) drivers;\n  - SoC Audio for Freescale CPUs drivers;\n  - Intel ASoC drivers;\n  - MediaTek ASoC drivers;\n  - Amlogic Meson SoC drivers;\n  - SoC audio core drivers;\n  - SOF drivers;\n  - Sound sequencer drivers;\n  - USB sound devices;\n  - Real-Time Linux Analysis tools;\n(CVE-2024-43911, CVE-2024-46762, CVE-2024-46794, CVE-2024-43843,\nCVE-2024-42229, CVE-2024-43888, CVE-2024-44978, CVE-2024-46693,\nCVE-2024-46695, CVE-2024-42290, CVE-2024-42067, CVE-2024-45012,\nCVE-2024-42316, CVE-2024-47665, CVE-2024-41052, CVE-2024-42074,\nCVE-2024-41058, CVE-2024-44975, CVE-2024-46709, CVE-2024-46871,\nCVE-2024-42090, CVE-2024-42296, CVE-2024-42096, CVE-2024-42146,\nCVE-2024-46855, CVE-2024-39487, CVE-2024-43825, CVE-2024-42066,\nCVE-2024-42126, CVE-2024-41022, CVE-2024-41025, CVE-2023-52888,\nCVE-2024-46702, CVE-2024-42269, CVE-2024-41082, CVE-2024-42284,\nCVE-2024-42227, CVE-2024-41017, CVE-2024-42250, CVE-2024-46778,\nCVE-2024-47661, CVE-2024-46727, CVE-2024-46845, CVE-2024-44953,\nCVE-2024-47659, CVE-2024-42137, CVE-2024-42245, CVE-2024-41096,\nCVE-2024-46829, CVE-2024-41053, CVE-2024-46782, CVE-2024-44972,\nCVE-2024-41095, CVE-2024-42239, CVE-2024-42127, CVE-2024-42292,\nCVE-2024-46752, CVE-2024-46679, CVE-2024-41076, CVE-2024-46784,\nCVE-2024-46786, CVE-2024-46678, CVE-2024-44957, CVE-2024-46755,\nCVE-2024-47660, CVE-2024-41067, CVE-2024-46838, CVE-2024-43879,\nCVE-2024-45007, CVE-2024-45025, CVE-2024-45001, CVE-2024-41009,\nCVE-2024-41051, CVE-2024-46836, CVE-2024-49984, CVE-2024-45028,\nCVE-2024-43871, CVE-2024-46783, CVE-2024-42272, CVE-2024-42087,\nCVE-2024-46785, CVE-2024-42276, CVE-2024-47658, CVE-2024-46761,\nCVE-2024-46715, CVE-2024-46676, CVE-2024-43824, CVE-2024-42100,\nCVE-2024-46745, CVE-2024-41084, CVE-2024-41086, CVE-2024-45015,\nCVE-2024-46797, CVE-2024-42160, CVE-2024-46706, CVE-2024-46803,\nCVE-2024-46708, CVE-2024-47669, CVE-2024-45009, CVE-2024-41021,\nCVE-2024-42159, CVE-2024-42321, CVE-2024-46868, CVE-2024-41078,\nCVE-2024-42303, CVE-2024-45027, CVE-2024-42309, CVE-2024-43849,\nCVE-2024-43907, CVE-2024-43899, CVE-2024-43823, CVE-2024-42232,\nCVE-2024-44937, CVE-2024-41046, CVE-2024-42237, CVE-2024-42063,\nCVE-2024-42065, CVE-2024-42154, CVE-2024-42259, CVE-2024-46698,\nCVE-2024-46741, CVE-2024-45020, CVE-2024-42151, CVE-2024-41073,\nCVE-2024-46719, CVE-2024-42295, CVE-2024-46859, CVE-2024-41035,\nCVE-2024-46751, CVE-2024-47667, CVE-2024-46728, CVE-2024-46824,\nCVE-2024-42121, CVE-2024-46776, CVE-2024-46768, CVE-2024-43908,\nCVE-2024-43900, CVE-2024-46707, CVE-2024-44934, CVE-2024-41062,\nCVE-2024-42304, CVE-2024-42312, CVE-2024-42157, CVE-2024-41092,\nCVE-2024-41041, CVE-2024-43832, CVE-2024-41039, CVE-2024-44962,\nCVE-2024-46858, CVE-2024-43856, CVE-2024-41060, CVE-2024-45010,\nCVE-2024-41044, CVE-2024-44942, CVE-2024-42307, CVE-2024-44984,\nCVE-2024-41075, CVE-2024-43817, CVE-2024-46791, CVE-2024-46853,\nCVE-2024-42301, CVE-2024-44993, CVE-2024-41094, CVE-2024-27022,\nCVE-2024-41088, CVE-2024-43883, CVE-2024-41087, CVE-2024-46780,\nCVE-2024-42070, CVE-2024-44965, CVE-2024-46823, CVE-2024-46737,\nCVE-2024-44982, CVE-2024-46697, CVE-2024-45021, CVE-2024-44987,\nCVE-2024-41072, CVE-2024-41063, CVE-2024-46757, CVE-2024-46831,\nCVE-2024-44966, CVE-2024-42322, CVE-2024-42231, CVE-2024-46717,\nCVE-2024-41065, CVE-2024-44969, CVE-2023-52887, CVE-2024-42105,\nCVE-2024-44971, CVE-2024-46798, CVE-2024-42262, CVE-2024-44938,\nCVE-2024-42088, CVE-2024-44970, CVE-2024-43876, CVE-2024-46800,\nCVE-2024-42086, CVE-2024-43826, CVE-2024-46729, CVE-2024-46747,\nCVE-2024-46691, CVE-2024-46723, CVE-2024-41018, CVE-2024-42258,\nCVE-2024-41081, CVE-2024-41049, CVE-2024-43837, CVE-2024-45008,\nCVE-2024-41047, CVE-2024-41019, CVE-2024-42152, CVE-2024-41090,\nCVE-2024-46716, CVE-2024-42104, CVE-2024-46804, CVE-2024-43852,\nCVE-2024-42129, CVE-2024-46870, CVE-2024-41093, CVE-2024-45011,\nCVE-2024-41064, CVE-2024-46722, CVE-2024-42286, CVE-2024-45026,\nCVE-2024-46818, CVE-2024-42281, CVE-2024-43854, CVE-2024-41037,\nCVE-2024-44946, CVE-2024-41012, CVE-2024-41098, CVE-2024-42263,\nCVE-2024-42095, CVE-2024-46756, CVE-2024-43913, CVE-2024-46822,\nCVE-2024-44944, CVE-2024-42156, CVE-2024-42073, CVE-2024-42093,\nCVE-2024-44931, CVE-2024-42223, CVE-2024-42264, CVE-2024-42278,\nCVE-2024-46759, CVE-2024-46826, CVE-2024-43828, CVE-2024-42318,\nCVE-2024-42240, CVE-2024-45000, CVE-2024-43909, CVE-2024-46792,\nCVE-2024-42109, CVE-2024-43867, CVE-2024-42130, CVE-2024-42244,\nCVE-2024-44977, CVE-2024-46774, CVE-2024-41030, CVE-2024-42310,\nCVE-2024-42138, CVE-2024-42317, CVE-2024-42224, CVE-2024-46694,\nCVE-2024-46815, CVE-2024-46677, CVE-2024-46763, CVE-2024-46860,\nCVE-2024-46767, CVE-2024-42111, CVE-2024-41020, CVE-2024-46726,\nCVE-2024-42117, CVE-2024-43831, CVE-2024-42285, CVE-2024-46842,\nCVE-2024-43857, CVE-2024-41031, CVE-2024-43834, CVE-2024-42135,\nCVE-2024-42241, CVE-2024-46846, CVE-2024-44988, CVE-2024-43892,\nCVE-2024-44991, CVE-2024-46806, CVE-2024-41015, CVE-2024-43906,\nCVE-2024-42238, CVE-2024-46779, CVE-2024-41010, CVE-2024-41068,\nCVE-2024-46730, CVE-2024-46827, CVE-2024-42120, CVE-2024-41059,\nCVE-2024-46850, CVE-2023-52889, CVE-2024-45017, CVE-2024-45003,\nCVE-2024-46844, CVE-2024-46816, CVE-2024-46811, CVE-2024-41023,\nCVE-2024-44948, CVE-2024-46753, CVE-2024-45002, CVE-2024-42251,\nCVE-2024-46713, CVE-2024-42273, CVE-2024-46733, CVE-2024-46739,\nCVE-2024-42108, CVE-2024-41085, CVE-2024-41033, CVE-2024-42298,\nCVE-2024-46835, CVE-2024-39472, CVE-2024-47663, CVE-2024-43859,\nCVE-2024-43820, CVE-2024-42118, CVE-2024-41036, CVE-2024-47683,\nCVE-2024-42161, CVE-2024-42235, CVE-2024-43861, CVE-2024-43863,\nCVE-2024-47668, CVE-2024-46685, CVE-2024-43864, CVE-2024-46749,\nCVE-2024-44983, CVE-2024-46841, CVE-2024-42082, CVE-2024-43818,\nCVE-2024-41071, CVE-2024-45006, CVE-2024-42080, CVE-2024-46825,\nCVE-2024-46687, CVE-2024-44959, CVE-2024-43835, CVE-2024-43891,\nCVE-2024-46851, CVE-2024-42248, CVE-2024-42103, CVE-2024-42079,\nCVE-2024-42068, CVE-2024-47664, CVE-2024-46854, CVE-2024-44973,\nCVE-2024-42077, CVE-2024-46821, CVE-2024-43886, CVE-2024-41089,\nCVE-2024-43850, CVE-2024-44995, CVE-2024-46809, CVE-2024-42084,\nCVE-2024-46758, CVE-2024-47662, CVE-2024-43839, CVE-2024-46738,\nCVE-2024-41034, CVE-2024-42228, CVE-2024-42147, CVE-2024-43855,\nCVE-2024-41032, CVE-2024-46819, CVE-2024-44989, CVE-2024-42265,\nCVE-2024-42110, CVE-2024-42155, CVE-2024-45005, CVE-2024-45016,\nCVE-2024-42141, CVE-2024-43821, CVE-2024-42299, CVE-2024-44950,\nCVE-2024-42279, CVE-2024-44943, CVE-2024-43904, CVE-2024-42268,\nCVE-2024-42089, CVE-2024-46807, CVE-2024-44996, CVE-2024-42069,\nCVE-2024-46672, CVE-2024-44940, CVE-2024-42270, CVE-2024-46735,\nCVE-2024-42319, CVE-2024-46754, CVE-2024-46861, CVE-2024-42277,\nCVE-2024-41054, CVE-2024-42131, CVE-2024-41056, CVE-2024-44963,\nCVE-2024-42267, CVE-2024-42283, CVE-2024-42320, CVE-2024-46740,\nCVE-2024-46787, CVE-2024-43895, CVE-2024-43881, CVE-2024-44961,\nCVE-2024-43910, CVE-2024-43875, CVE-2024-42289, CVE-2024-43853,\nCVE-2024-42315, CVE-2024-43884, CVE-2024-46867, CVE-2024-43912,\nCVE-2024-41007, CVE-2024-46743, CVE-2024-46675, CVE-2024-43877,\nCVE-2024-39486, CVE-2024-41050, CVE-2024-43858, CVE-2024-45018,\nCVE-2024-46744, CVE-2024-46750, CVE-2024-46840, CVE-2024-42150,\nCVE-2024-41028, CVE-2024-42091, CVE-2024-43894, CVE-2024-43869,\nCVE-2024-42132, CVE-2024-46777, CVE-2024-42106, CVE-2024-46848,\nCVE-2024-41038, CVE-2024-46711, CVE-2024-43833, CVE-2024-46710,\nCVE-2024-46812, CVE-2024-42311, CVE-2024-46701, CVE-2024-46683,\nCVE-2024-45029, CVE-2024-46830, CVE-2024-46857, CVE-2024-44979,\nCVE-2024-44999, CVE-2024-44985, CVE-2024-46773, CVE-2024-45022,\nCVE-2024-46772, CVE-2024-44960, CVE-2024-42243, CVE-2024-42158,\nCVE-2024-43819, CVE-2024-45030, CVE-2024-42085, CVE-2024-42274,\nCVE-2024-44986, CVE-2024-41048, CVE-2024-42098, CVE-2024-46680,\nCVE-2023-52918, CVE-2024-46673, CVE-2024-46834, CVE-2024-42288,\nCVE-2024-44998, CVE-2024-42113, CVE-2024-42094, CVE-2024-42225,\nCVE-2024-42112, CVE-2024-42153, CVE-2024-43880, CVE-2024-43905,\nCVE-2024-43902, CVE-2024-46681, CVE-2024-42236, CVE-2024-42294,\nCVE-2024-46793, CVE-2024-43882, CVE-2024-44947, CVE-2024-46849,\nCVE-2024-44954, CVE-2024-46852, CVE-2024-41070, CVE-2024-41069,\nCVE-2024-46864, CVE-2024-46703, CVE-2024-43829, CVE-2024-46802,\nCVE-2024-42101, CVE-2024-44990, CVE-2024-43830, CVE-2024-41029,\nCVE-2024-43866, CVE-2024-43889, CVE-2024-42230, CVE-2024-46692,\nCVE-2024-42133, CVE-2024-45013, CVE-2024-42076, CVE-2024-46810,\nCVE-2024-42128, CVE-2024-46718, CVE-2024-46814, CVE-2024-43841,\nCVE-2024-43873, CVE-2024-42092, CVE-2024-41074, CVE-2024-41083,\nCVE-2024-46731, CVE-2024-43842, CVE-2024-41077, CVE-2024-46720,\nCVE-2024-46795, CVE-2024-46813, CVE-2024-46805, CVE-2024-42142,\nCVE-2024-42291, CVE-2024-43846, CVE-2024-41057, CVE-2024-43870,\nCVE-2024-44980, CVE-2024-46866, CVE-2024-43827, CVE-2024-43840,\nCVE-2024-42280, CVE-2024-42261, CVE-2024-42246, CVE-2024-42115,\nCVE-2024-46686, CVE-2024-43860, CVE-2024-46808, CVE-2024-42149,\nCVE-2024-46828, CVE-2024-44935, CVE-2024-43847, CVE-2024-44967,\nCVE-2024-46817, CVE-2024-46721, CVE-2024-42305, CVE-2024-46766,\nCVE-2024-43914, CVE-2024-46760, CVE-2024-41061, CVE-2024-41091,\nCVE-2024-43890, CVE-2024-42314, CVE-2024-42064, CVE-2024-42302,\nCVE-2024-43887, CVE-2024-46832, CVE-2024-46765, CVE-2024-46770,\nCVE-2024-41080, CVE-2024-42253, CVE-2024-44941, CVE-2024-42306,\nCVE-2024-41027, CVE-2024-46689, CVE-2024-46781, CVE-2024-42247,\nCVE-2024-41066, CVE-2024-42287, CVE-2024-41097, CVE-2024-44939,\nCVE-2024-45019, CVE-2024-47674, CVE-2024-46705, CVE-2024-42119,\nCVE-2024-46725, CVE-2024-46746, CVE-2024-46732, CVE-2024-41042,\nCVE-2024-44958, CVE-2024-42114, CVE-2024-43893, CVE-2024-47666,\nCVE-2024-46843, CVE-2024-42252, CVE-2024-42102, CVE-2024-42136,\nCVE-2024-41045, CVE-2024-42260, CVE-2024-46771, CVE-2024-42124,\nCVE-2024-42297, CVE-2024-42271, CVE-2024-43845, CVE-2024-46775,\nCVE-2024-41079, CVE-2024-43868, CVE-2024-42140, CVE-2024-42313,\nCVE-2024-42145, CVE-2024-46724, CVE-2024-46788, CVE-2024-42234,\nCVE-2024-42144, CVE-2024-44974, CVE-2024-42097, CVE-2024-46714,\nCVE-2024-41055, CVE-2024-44956)\n","status":"published","published":"2024-12-12T17:47:44Z","modified":"2026-10-29T20:02:38.448595714Z","updated_at":"2026-11-02T16:58:18.876384Z"}]}}