{"id":"CVE-2024-38667","aliases":["AZL-42901","BELL-CVE-2024-38667","DEBIAN-CVE-2024-38667","EUVD-2024-37519","GHSA-cqg5-mcpx-q78p","MGASA-2024-0263","MGASA-2024-0266","OESA-2024-2321","OESA-2024-2322","OESA-2024-2324","OESA-2025-2802","ROOT-OS-DEBIAN-11-CVE-2024-38667","UBUNTU-CVE-2024-38667","USN-6999-1","USN-6999-2","USN-7004-1","USN-7005-1","USN-7005-2","USN-7008-1","USN-7029-1","USN-7166-1","USN-7166-2","USN-7166-3","USN-7166-4","USN-7186-1","USN-7186-2","USN-7194-1"],"status":"published","title":"riscv: prevent pt_regs corruption for secondary idle threads","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: prevent pt_regs corruption for secondary idle threads\n\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\n\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\"riscv: prevent stack corruption by reserving task_pt_regs(p) early\").\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.","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":"primary","from":"nvd"},"epss":{"day":"2026-11-10","score":0.00228,"percentile":0.13692,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-787"],"published":"2024-06-24T13:52:25Z","modified":"2026-11-11T09:38:23Z","fixes":[{"ecosystem":"Azure Linux:3","package":"kernel","fixed_in":["6.6.35.1-4"],"sources":["osv"]},{"ecosystem":"Alpaquita:23","package":"linux-lts","fixed_in":["6.1.97-r0"],"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.1.93","6.6.33","6.9.4"],"sources":["osv"]},{"ecosystem":"Debian:12","package":"linux","fixed_in":["6.1.94-1"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"linux","fixed_in":["6.9.7-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"linux","fixed_in":["6.9.7-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":"Ubuntu:20.04:LTS","package":"linux-aws-5.15","fixed_in":["5.15.0-1073.79~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-5.15","fixed_in":["5.15.0-1078.87~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"linux-gcp-5.15","fixed_in":["5.15.0-1072.80~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"linux-hwe-5.15","fixed_in":["5.15.0-127.137~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"linux-ibm-5.15","fixed_in":["5.15.0-1066.69~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"linux-intel-iotg-5.15","fixed_in":["5.15.0-1071.77~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"linux-lowlatency-hwe-5.15","fixed_in":["5.15.0-127.137~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"linux-nvidia-tegra-5.15","fixed_in":["5.15.0-1032.32~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"linux-oracle-5.15","fixed_in":["5.15.0-1071.77~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"linux-riscv-5.15","fixed_in":["5.15.0-1069.73~20.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux","fixed_in":["5.15.0-127.137"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws","fixed_in":["5.15.0-1073.79"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-6.8","fixed_in":["6.8.0-1015.16~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure","fixed_in":["5.15.0-1078.87"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-6.8","fixed_in":["6.8.0-1014.16~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-fde","fixed_in":["5.15.0-1078.87.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp","fixed_in":["5.15.0-1072.80"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-6.8","fixed_in":["6.8.0-1014.16~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-gke","fixed_in":["5.15.0-1070.76"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-gkeop","fixed_in":["5.15.0-1056.63"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-hwe-6.8","fixed_in":["6.8.0-45.45~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-ibm","fixed_in":["5.15.0-1066.69"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-ibm-6.8","fixed_in":["6.8.0-1012.12~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-intel-iotg","fixed_in":["5.15.0-1071.77"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-kvm","fixed_in":["5.15.0-1070.75"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency","fixed_in":["5.15.0-127.137"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-6.8","fixed_in":["6.8.0-44.44.1~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia","fixed_in":["5.15.0-1068.69"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-6.8","fixed_in":["6.8.0-1013.14~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-tegra","fixed_in":["5.15.0-1032.32"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-tegra-igx","fixed_in":["5.15.0-1020.20"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-oracle","fixed_in":["5.15.0-1071.77"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-oracle-6.8","fixed_in":["6.8.0-1012.12~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-raspi","fixed_in":["5.15.0-1066.69"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-riscv-6.8","fixed_in":["6.8.0-44.44.1~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"linux-xilinx-zynqmp","fixed_in":["5.15.0-1039.43"],"sources":["osv"]},{"ecosystem":"Ubuntu:Nvidia-BlueField:22.04:LTS","package":"linux-bluefield","fixed_in":["5.15.0-1057.59"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:Realtime:22.04:LTS","package":"linux-intel-iot-realtime","fixed_in":["5.15.0-1066.68"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:Realtime:22.04:LTS","package":"linux-realtime","fixed_in":["5.15.0-1074.82"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:Realtime:22.04:LTS","package":"linux-realtime-6.8","fixed_in":["6.8.1-1008.8~22.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:FIPS-updates:22.04:LTS","package":"linux-aws-fips","fixed_in":["5.15.0-1073.79+fips1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:FIPS-updates:22.04:LTS","package":"linux-azure-fips","fixed_in":["5.15.0-1078.87+fips1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:FIPS-updates:22.04:LTS","package":"linux-fips","fixed_in":["5.15.0-127.137+fips1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:FIPS-updates:22.04:LTS","package":"linux-gcp-fips","fixed_in":["5.15.0-1072.80+fips1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux","fixed_in":["6.8.0-44.44"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-aws","fixed_in":["6.8.0-1015.16"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure","fixed_in":["6.8.0-1014.16"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp","fixed_in":["6.8.0-1014.16"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-gke","fixed_in":["6.8.0-1010.13"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-ibm","fixed_in":["6.8.0-1012.12"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-lowlatency","fixed_in":["6.8.0-44.44.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia","fixed_in":["6.8.0-1013.14"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia-lowlatency","fixed_in":["6.8.0-1013.14.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.8","fixed_in":["6.8.0-1012.12"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-oracle","fixed_in":["6.8.0-1012.12"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-raspi","fixed_in":["6.8.0-1011.12"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-riscv","fixed_in":["6.8.0-44.44.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-raspi-realtime","fixed_in":["6.8.0-2010.10"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-realtime","fixed_in":["6.8.1-1008.8"],"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:3","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.35.1-4"}]}]},{"source":"osv","ecosystem":"Alpaquita:23","package":"linux-lts","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.1.92-r0"},{"fixed":"6.1.97-r0"}]}]},{"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":"5.7.0"},{"fixed":"6.1.93"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.2.0"},{"fixed":"6.6.33"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.7.0"},{"fixed":"6.9.4"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.94-1"}]}],"versions":["6.1.27-1","6.1.37-1","6.1.38-1","6.1.38-2","6.1.38-2~bpo11+1","6.1.38-3","6.1.38-4","6.1.38-4~bpo11+1","6.1.52-1","6.1.55-1","6.1.55-1~bpo11+1","6.1.64-1","6.1.66-1","6.1.67-1","6.1.69-1","6.1.69-1~bpo11+1","6.1.76-1","6.1.76-1~bpo11+1","6.1.82-1","6.1.85-1","6.1.90-1","6.1.90-1~bpo11+1","6.1.94-1~bpo11+1"]},{"source":"osv","ecosystem":"Debian:13","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.9.7-1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.9.7-1"}]}]},{"source":"osv","ecosystem":"Mageia:9","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.37-1.mga9"}]}],"bundled":320},{"source":"osv","ecosystem":"Mageia:9","package":"kmod-xtables-addons","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.24-59.mga9"}]}],"bundled":320},{"source":"osv","ecosystem":"Mageia:9","package":"kmod-virtualbox","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"7.0.18-50.mga9"}]}],"bundled":320},{"source":"osv","ecosystem":"Mageia:9","package":"dwarves","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.27-1.mga9"}]}],"bundled":320},{"source":"osv","ecosystem":"Mageia:9","package":"kernel-linus","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.37-1.mga9"}]}],"bundled":320},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP4","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-234.0.0.133.oe2203sp4"}]}],"bundled":62},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP3","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-234.0.0.136.oe2203sp3"}]}],"bundled":62},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP1","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-136.99.0.180.oe2203sp1"}]}],"bundled":74},{"source":"osv","ecosystem":"openEuler:24.03-LTS","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-127.0.0.113.oe2403"}]}],"bundled":95},{"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":"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-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.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1073.79~20.04.1"}]}],"versions":["5.15.0-1014.18~20.04.1","5.15.0-1015.19~20.04.1","5.15.0-1017.21~20.04.1","5.15.0-1019.23~20.04.1","5.15.0-1020.24~20.04.1","5.15.0-1021.25~20.04.1","5.15.0-1022.26~20.04.1","5.15.0-1023.27~20.04.1","5.15.0-1026.30~20.04.2","5.15.0-1027.31~20.04.1","5.15.0-1028.32~20.04.1","5.15.0-1030.34~20.04.1","5.15.0-1031.35~20.04.1","5.15.0-1033.37~20.04.1","5.15.0-1034.38~20.04.1","5.15.0-1035.39~20.04.1","5.15.0-1036.40~20.04.1","5.15.0-1037.41~20.04.1","5.15.0-1038.43~20.04.1","5.15.0-1039.44~20.04.1","5.15.0-1040.45~20.04.1","5.15.0-1041.46~20.04.1","5.15.0-1043.48~20.04.1","5.15.0-1044.49~20.04.1","5.15.0-1045.50~20.04.1","5.15.0-1047.52~20.04.1","5.15.0-1048.53~20.04.1","5.15.0-1049.54~20.04.1","5.15.0-1050.55~20.04.1","5.15.0-1051.56~20.04.1","5.15.0-1052.57~20.04.1","5.15.0-1053.58~20.04.1","5.15.0-1055.60~20.04.1","5.15.0-1056.61~20.04.1","5.15.0-1057.63~20.04.1","5.15.0-1058.64~20.04.1","5.15.0-1061.67~20.04.1","5.15.0-1062.68~20.04.1","5.15.0-1063.69~20.04.1","5.15.0-1064.70~20.04.1","5.15.0-1065.71~20.04.1","5.15.0-1066.72~20.04.1","5.15.0-1067.73~20.04.1","5.15.0-1068.74~20.04.1","5.15.0-1069.75~20.04.1","5.15.0-1070.76~20.04.1","5.15.0-1071.77~20.04.1","5.15.0-1072.78~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1078.87~20.04.1"}]}],"versions":["5.15.0-1007.8~20.04.1","5.15.0-1008.9~20.04.1","5.15.0-1013.16~20.04.1","5.15.0-1014.17~20.04.1","5.15.0-1017.20~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.29~20.04.1","5.15.0-1029.36~20.04.1","5.15.0-1030.37~20.04.1","5.15.0-1031.38~20.04.1","5.15.0-1033.40~20.04.1","5.15.0-1034.41~20.04.1","5.15.0-1035.42~20.04.1","5.15.0-1036.43~20.04.1","5.15.0-1037.44~20.04.1","5.15.0-1038.45~20.04.1","5.15.0-1039.46~20.04.1","5.15.0-1040.47~20.04.1","5.15.0-1041.48~20.04.1","5.15.0-1042.49~20.04.1","5.15.0-1043.50~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-1049.56~20.04.1","5.15.0-1050.57~20.04.1","5.15.0-1051.59~20.04.1","5.15.0-1052.60~20.04.1","5.15.0-1053.61~20.04.1","5.15.0-1054.62~20.04.1","5.15.0-1056.64~20.04.1","5.15.0-1057.65~20.04.1","5.15.0-1058.66~20.04.2","5.15.0-1059.67~20.04.1","5.15.0-1060.69~20.04.1","5.15.0-1061.70~20.04.1","5.15.0-1063.72~20.04.1","5.15.0-1064.73~20.04.1","5.15.0-1065.74~20.04.1","5.15.0-1067.76~20.04.1","5.15.0-1068.77~20.04.1","5.15.0-1070.79~20.04.1","5.15.0-1071.80~20.04.1","5.15.0-1072.81~20.04.1","5.15.0-1073.82~20.04.1","5.15.0-1074.83~20.04.1","5.15.0-1075.84~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gcp-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1072.80~20.04.1"}]}],"versions":["5.15.0-1006.9~20.04.1","5.15.0-1012.17~20.04.1","5.15.0-1013.18~20.04.1","5.15.0-1016.21~20.04.1","5.15.0-1017.23~20.04.2","5.15.0-1018.24~20.04.1","5.15.0-1021.28~20.04.1","5.15.0-1022.29~20.04.1","5.15.0-1025.32~20.04.2","5.15.0-1026.33~20.04.1","5.15.0-1027.34~20.04.1","5.15.0-1029.36~20.04.1","5.15.0-1030.37~20.04.1","5.15.0-1031.38~20.04.1","5.15.0-1032.40~20.04.1","5.15.0-1033.41~20.04.1","5.15.0-1034.42~20.04.1","5.15.0-1035.43~20.04.1","5.15.0-1036.44~20.04.1","5.15.0-1037.45~20.04.1","5.15.0-1038.46~20.04.1","5.15.0-1039.47~20.04.1","5.15.0-1040.48~20.04.1","5.15.0-1041.49~20.04.1","5.15.0-1042.50~20.04.1","5.15.0-1044.52~20.04.1","5.15.0-1045.53~20.04.2","5.15.0-1046.54~20.04.1","5.15.0-1047.55~20.04.1","5.15.0-1048.56~20.04.1","5.15.0-1049.57~20.04.1","5.15.0-1051.59~20.04.1","5.15.0-1052.60~20.04.1","5.15.0-1053.61~20.04.1","5.15.0-1054.62~20.04.1","5.15.0-1055.63~20.04.1","5.15.0-1058.66~20.04.1","5.15.0-1059.67~20.04.1","5.15.0-1060.68~20.04.1","5.15.0-1062.70~20.04.1","5.15.0-1065.73~20.04.1","5.15.0-1066.74~20.04.1","5.15.0-1067.75~20.04.1","5.15.0-1068.76~20.04.1","5.15.0-1069.77~20.04.1","5.15.0-1070.78~20.04.1","5.15.0-1071.79~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-hwe-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-127.137~20.04.1"}]}],"versions":["5.15.0-33.34~20.04.1","5.15.0-41.44~20.04.1","5.15.0-43.46~20.04.1","5.15.0-46.49~20.04.1","5.15.0-48.54~20.04.1","5.15.0-50.56~20.04.1","5.15.0-52.58~20.04.1","5.15.0-53.59~20.04.1","5.15.0-56.62~20.04.1","5.15.0-57.63~20.04.1","5.15.0-58.64~20.04.1","5.15.0-60.66~20.04.1","5.15.0-67.74~20.04.1","5.15.0-69.76~20.04.1","5.15.0-70.77~20.04.1","5.15.0-71.78~20.04.1","5.15.0-72.79~20.04.1","5.15.0-73.80~20.04.1","5.15.0-75.82~20.04.1","5.15.0-76.83~20.04.1","5.15.0-78.85~20.04.1","5.15.0-79.86~20.04.2","5.15.0-82.91~20.04.1","5.15.0-83.92~20.04.1","5.15.0-84.93~20.04.1","5.15.0-86.96~20.04.1","5.15.0-87.97~20.04.1","5.15.0-88.98~20.04.1","5.15.0-89.99~20.04.1","5.15.0-91.101~20.04.1","5.15.0-92.102~20.04.1","5.15.0-94.104~20.04.1","5.15.0-97.107~20.04.1","5.15.0-100.110~20.04.1","5.15.0-101.111~20.04.1","5.15.0-102.112~20.04.1","5.15.0-105.115~20.04.1","5.15.0-106.116~20.04.1","5.15.0-107.117~20.04.1","5.15.0-113.123~20.04.1","5.15.0-116.126~20.04.1","5.15.0-117.127~20.04.1","5.15.0-118.128~20.04.1","5.15.0-119.129~20.04.1","5.15.0-121.131~20.04.1","5.15.0-122.132~20.04.1","5.15.0-124.134~20.04.1","5.15.0-125.135~20.04.1","5.15.0-126.136~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-ibm-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1066.69~20.04.1"}]}],"versions":["5.15.0-1033.36~20.04.1","5.15.0-1034.37~20.04.1","5.15.0-1035.38~20.04.1","5.15.0-1036.39~20.04.1","5.15.0-1037.40~20.04.1","5.15.0-1038.41~20.04.1","5.15.0-1040.43~20.04.1","5.15.0-1041.44~20.04.1","5.15.0-1042.45~20.04.1","5.15.0-1043.46~20.04.1","5.15.0-1044.47~20.04.1","5.15.0-1045.48~20.04.1","5.15.0-1046.49~20.04.1","5.15.0-1047.50~20.04.1","5.15.0-1048.51~20.04.1","5.15.0-1049.52~20.04.1","5.15.0-1050.53~20.04.1","5.15.0-1053.56~20.04.1","5.15.0-1054.57~20.04.1","5.15.0-1055.58~20.04.1","5.15.0-1057.60~20.04.1","5.15.0-1058.61~20.04.1","5.15.0-1059.62~20.04.1","5.15.0-1060.63~20.04.1","5.15.0-1061.64~20.04.1","5.15.0-1062.65~20.04.1","5.15.0-1063.66~20.04.1","5.15.0-1064.67~20.04.1","5.15.0-1065.68~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-intel-iotg-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1071.77~20.04.1"}]}],"versions":["5.15.0-1003.5~20.04.1","5.15.0-1008.11~20.04.1","5.15.0-1010.14~20.04.1","5.15.0-1015.20~20.04.2","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-1021.26~20.04.1","5.15.0-1023.28~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-1030.35~20.04.1","5.15.0-1031.36~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-1040.46~20.04.1","5.15.0-1043.49~20.04.1","5.15.0-1045.51~20.04.1","5.15.0-1046.52~20.04.1","5.15.0-1048.54~20.04.1","5.15.0-1049.55~20.04.1","5.15.0-1050.56~20.04.1","5.15.0-1051.57~20.04.1","5.15.0-1052.58~20.04.1","5.15.0-1055.61~20.04.1","5.15.0-1058.64~20.04.1","5.15.0-1059.65~20.04.1","5.15.0-1060.66~20.04.1","5.15.0-1061.67~20.04.1","5.15.0-1062.68~20.04.1","5.15.0-1063.69~20.04.1","5.15.0-1064.70~20.04.1","5.15.0-1065.71~20.04.1","5.15.0-1066.72~20.04.1","5.15.0-1067.73~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-lowlatency-hwe-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-127.137~20.04.1"}]}],"versions":["5.15.0-33.34~20.04.1","5.15.0-42.45~20.04.1","5.15.0-43.46~20.04.1","5.15.0-46.49~20.04.1","5.15.0-48.54~20.04.1","5.15.0-50.56~20.04.1","5.15.0-52.58~20.04.1","5.15.0-53.59~20.04.1","5.15.0-56.62~20.04.1","5.15.0-58.64~20.04.1","5.15.0-60.66~20.04.1","5.15.0-67.74~20.04.1","5.15.0-69.76~20.04.1","5.15.0-70.77~20.04.1","5.15.0-71.78~20.04.1","5.15.0-72.79~20.04.1","5.15.0-73.80~20.04.1","5.15.0-75.82~20.04.1","5.15.0-76.83~20.04.1","5.15.0-78.85~20.04.1","5.15.0-79.88~20.04.1","5.15.0-82.91~20.04.1","5.15.0-83.92~20.04.1","5.15.0-84.93~20.04.1","5.15.0-86.95~20.04.1","5.15.0-87.96~20.04.1","5.15.0-88.98~20.04.1","5.15.0-89.99~20.04.1","5.15.0-91.101~20.04.1","5.15.0-92.102~20.04.1","5.15.0-94.104~20.04.1","5.15.0-97.107~20.04.1","5.15.0-100.110~20.04.1","5.15.0-101.111~20.04.1","5.15.0-102.112~20.04.1","5.15.0-105.115~20.04.1","5.15.0-106.116~20.04.1","5.15.0-107.117~20.04.1","5.15.0-110.120~20.04.1","5.15.0-113.123~20.04.1","5.15.0-116.126~20.04.1","5.15.0-117.127~20.04.1","5.15.0-118.128~20.04.1","5.15.0-119.129~20.04.1","5.15.0-121.131~20.04.1","5.15.0-122.132~20.04.1","5.15.0-124.134~20.04.1","5.15.0-125.135~20.04.1","5.15.0-126.136~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-nvidia-tegra-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1032.32~20.04.1"}]}],"versions":["5.15.0-1009.9~20.04.1","5.15.0-1010.10~20.04.1","5.15.0-1012.12~20.04.1","5.15.0-1014.14~20.04.1","5.15.0-1015.15~20.04.1","5.15.0-1016.16~20.04.1","5.15.0-1017.17~20.04.1","5.15.0-1018.18~20.04.1","5.15.0-1019.19~20.04.1","5.15.0-1020.20~20.04.1","5.15.0-1022.22~20.04.1","5.15.0-1025.25~20.04.1","5.15.0-1027.27~20.04.1","5.15.0-1030.30~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oracle-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1071.77~20.04.1"}]}],"versions":["5.15.0-1007.9~20.04.1","5.15.0-1013.17~20.04.1","5.15.0-1016.20~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-1021.27~20.04.1","5.15.0-1022.28~20.04.1","5.15.0-1025.31~20.04.2","5.15.0-1027.33~20.04.1","5.15.0-1029.35~20.04.1","5.15.0-1030.36~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-1041.47~20.04.1","5.15.0-1042.48~20.04.1","5.15.0-1044.50~20.04.1","5.15.0-1045.51~20.04.1","5.15.0-1046.52~20.04.1","5.15.0-1047.53~20.04.1","5.15.0-1048.54~20.04.1","5.15.0-1049.55~20.04.1","5.15.0-1050.56~20.04.1","5.15.0-1051.57~20.04.1","5.15.0-1052.58~20.04.1","5.15.0-1053.59~20.04.1","5.15.0-1054.60~20.04.1","5.15.0-1055.61~20.04.1","5.15.0-1058.64~20.04.1","5.15.0-1059.65~20.04.1","5.15.0-1061.67~20.04.1","5.15.0-1062.68~20.04.1","5.15.0-1063.69~20.04.1","5.15.0-1065.71~20.04.1","5.15.0-1066.72~20.04.1","5.15.0-1067.73~20.04.1","5.15.0-1068.74~20.04.1","5.15.0-1069.75~20.04.1","5.15.0-1070.76~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-riscv-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1069.73~20.04.1"}]}],"versions":["5.15.0-1015.17~20.04.1","5.15.0-1017.19~20.04.1","5.15.0-1018.21~20.04.1","5.15.0-1019.22~20.04.1","5.15.0-1022.26~20.04.1","5.15.0-1023.27~20.04.1","5.15.0-1026.30~20.04.2","5.15.0-1027.31~20.04.1","5.15.0-1028.32~20.04.1","5.15.0-1029.33~20.04.1","5.15.0-1030.34~20.04.1","5.15.0-1031.35~20.04.1","5.15.0-1032.36~20.04.1","5.15.0-1033.37~20.04.1","5.15.0-1034.38~20.04.1","5.15.0-1035.39~20.04.1","5.15.0-1036.40~20.04.2","5.15.0-1037.41~20.04.2","5.15.0-1038.42~20.04.2","5.15.0-1039.43~20.04.2","5.15.0-1040.44~20.04.3","5.15.0-1041.45~20.04.1","5.15.0-1043.47~20.04.1","5.15.0-1044.48~20.04.1","5.15.0-1045.49~20.04.1","5.15.0-1046.50~20.04.1","5.15.0-1047.51~20.04.1","5.15.0-1048.52~20.04.1","5.15.0-1049.53~20.04.2","5.15.0-1050.54~20.04.1","5.15.0-1051.55~20.04.1","5.15.0-1052.56~20.04.1","5.15.0-1053.57~20.04.1","5.15.0-1056.60~20.04.1","5.15.0-1057.61~20.04.1","5.15.0-1058.62~20.04.1","5.15.0-1059.63~20.04.1","5.15.0-1060.64~20.04.1","5.15.0-1061.65~20.04.1","5.15.0-1062.66~20.04.1","5.15.0-1063.67~20.04.1","5.15.0-1064.68~20.04.1","5.15.0-1065.69~20.04.1","5.15.0-1066.70~20.04.1","5.15.0-1067.71~20.04.1","5.15.0-1068.72~20.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-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","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-127.137"}]}],"versions":["5.13.0-19.19","5.15.0-17.17","5.15.0-18.18","5.15.0-22.22","5.15.0-23.23","5.15.0-25.25","5.15.0-27.28","5.15.0-30.31","5.15.0-33.34","5.15.0-35.36","5.15.0-37.39","5.15.0-39.42","5.15.0-40.43","5.15.0-41.44","5.15.0-43.46","5.15.0-46.49","5.15.0-47.51","5.15.0-48.54","5.15.0-50.56","5.15.0-52.58","5.15.0-53.59","5.15.0-56.62","5.15.0-57.63","5.15.0-58.64","5.15.0-60.66","5.15.0-67.74","5.15.0-69.76","5.15.0-70.77","5.15.0-71.78","5.15.0-72.79","5.15.0-73.80","5.15.0-75.82","5.15.0-76.83","5.15.0-78.85","5.15.0-79.86","5.15.0-82.91","5.15.0-83.92","5.15.0-84.93","5.15.0-86.96","5.15.0-87.97","5.15.0-88.98","5.15.0-89.99","5.15.0-91.101","5.15.0-92.102","5.15.0-94.104","5.15.0-97.107","5.15.0-100.110","5.15.0-101.111","5.15.0-102.112","5.15.0-105.115","5.15.0-106.116","5.15.0-107.117","5.15.0-112.122","5.15.0-113.123","5.15.0-116.126","5.15.0-117.127","5.15.0-118.128","5.15.0-119.129","5.15.0-121.131","5.15.0-122.132","5.15.0-124.134","5.15.0-125.135","5.15.0-126.136"]},{"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","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1073.79"}]}],"versions":["5.13.0-1005.6","5.15.0-1002.4","5.15.0-1003.5","5.15.0-1004.6","5.15.0-1005.7","5.15.0-1008.10","5.15.0-1009.11","5.15.0-1011.14","5.15.0-1013.17","5.15.0-1014.18","5.15.0-1015.19","5.15.0-1017.21","5.15.0-1019.23","5.15.0-1020.24","5.15.0-1021.25","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","5.15.0-1030.34","5.15.0-1031.35","5.15.0-1033.37","5.15.0-1034.38","5.15.0-1035.39","5.15.0-1036.40","5.15.0-1037.41","5.15.0-1038.43","5.15.0-1039.44","5.15.0-1040.45","5.15.0-1042.47","5.15.0-1043.48","5.15.0-1044.49","5.15.0-1045.50","5.15.0-1047.52","5.15.0-1048.53","5.15.0-1049.54","5.15.0-1050.55","5.15.0-1051.56","5.15.0-1052.57","5.15.0-1053.58","5.15.0-1055.60","5.15.0-1056.61","5.15.0-1057.63","5.15.0-1060.66","5.15.0-1061.67","5.15.0-1062.68","5.15.0-1063.69","5.15.0-1064.70","5.15.0-1065.71","5.15.0-1066.72","5.15.0-1067.73","5.15.0-1068.74","5.15.0-1069.75","5.15.0-1070.76","5.15.0-1071.77","5.15.0-1072.78"]},{"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-1015.16~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"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1078.87"}]}],"versions":["5.13.0-1006.7","5.15.0-1001.2","5.15.0-1002.3","5.15.0-1003.4","5.15.0-1005.6","5.15.0-1007.8","5.15.0-1008.9","5.15.0-1010.12","5.15.0-1012.15","5.15.0-1013.16","5.15.0-1014.17","5.15.0-1017.20","5.15.0-1019.24","5.15.0-1020.25","5.15.0-1021.26","5.15.0-1022.27","5.15.0-1023.29","5.15.0-1024.30","5.15.0-1029.36","5.15.0-1030.37","5.15.0-1031.38","5.15.0-1033.40","5.15.0-1034.41","5.15.0-1035.42","5.15.0-1036.43","5.15.0-1037.44","5.15.0-1038.45","5.15.0-1039.46","5.15.0-1040.47","5.15.0-1041.48","5.15.0-1042.49","5.15.0-1044.51","5.15.0-1045.52","5.15.0-1046.53","5.15.0-1047.54","5.15.0-1049.56","5.15.0-1050.57","5.15.0-1051.59","5.15.0-1052.60","5.15.0-1053.61","5.15.0-1054.62","5.15.0-1056.64","5.15.0-1057.65","5.15.0-1058.66","5.15.0-1059.67","5.15.0-1060.69","5.15.0-1061.70","5.15.0-1063.72","5.15.0-1064.73","5.15.0-1066.75","5.15.0-1067.76","5.15.0-1068.77","5.15.0-1070.79","5.15.0-1071.80","5.15.0-1072.81","5.15.0-1073.82","5.15.0-1074.83","5.15.0-1075.84"]},{"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-1014.16~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"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-fde","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1078.87.1"}]}],"versions":["5.15.0-1019.24.1","5.15.0-1024.30.1","5.15.0-1029.36.1","5.15.0-1030.37.1","5.15.0-1031.38.1","5.15.0-1033.40.1","5.15.0-1034.41.1","5.15.0-1035.42.1","5.15.0-1036.43.1","5.15.0-1037.44.1","5.15.0-1038.45.1","5.15.0-1039.46.1","5.15.0-1041.48.1","5.15.0-1042.49.1","5.15.0-1044.51.1","5.15.0-1045.52.1","5.15.0-1046.53.1","5.15.0-1047.54.1","5.15.0-1049.56.1","5.15.0-1050.57.1","5.15.0-1051.59.1","5.15.0-1052.60.1","5.15.0-1053.61.1","5.15.0-1054.62.1","5.15.0-1056.64.1","5.15.0-1057.65.1","5.15.0-1058.66.1","5.15.0-1059.67.1","5.15.0-1060.69.1","5.15.0-1061.70.1","5.15.0-1063.72.1","5.15.0-1064.73.1","5.15.0-1065.74.1","5.15.0-1067.76.1","5.15.0-1068.77.1","5.15.0-1070.79.1","5.15.0-1071.80.1","5.15.0-1072.81.1","5.15.0-1073.82.1","5.15.0-1076.85.1"]},{"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","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1072.80"}]}],"versions":["5.13.0-1005.6","5.15.0-1001.3","5.15.0-1002.5","5.15.0-1003.6","5.15.0-1004.7","5.15.0-1005.8","5.15.0-1006.9","5.15.0-1008.12","5.15.0-1010.15","5.15.0-1013.18","5.15.0-1016.21","5.15.0-1017.23","5.15.0-1018.24","5.15.0-1019.25","5.15.0-1021.28","5.15.0-1022.29","5.15.0-1025.32","5.15.0-1026.33","5.15.0-1027.34","5.15.0-1029.36","5.15.0-1030.37","5.15.0-1031.38","5.15.0-1032.40","5.15.0-1034.42","5.15.0-1035.43","5.15.0-1036.44","5.15.0-1037.45","5.15.0-1038.46","5.15.0-1039.47","5.15.0-1040.48","5.15.0-1041.49","5.15.0-1042.50","5.15.0-1044.52","5.15.0-1045.53","5.15.0-1046.54","5.15.0-1047.55","5.15.0-1048.56","5.15.0-1049.57","5.15.0-1051.59","5.15.0-1052.60","5.15.0-1053.61","5.15.0-1054.62","5.15.0-1055.63","5.15.0-1058.66","5.15.0-1059.67","5.15.0-1060.68","5.15.0-1062.70","5.15.0-1063.71","5.15.0-1064.72","5.15.0-1065.73","5.15.0-1066.74","5.15.0-1067.75","5.15.0-1068.76","5.15.0-1069.77","5.15.0-1070.78","5.15.0-1071.79"]},{"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-1014.16~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"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gke","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1070.76"}]}],"versions":["5.15.0-1002.2","5.15.0-1003.3","5.15.0-1004.5","5.15.0-1005.6","5.15.0-1006.7","5.15.0-1008.10","5.15.0-1010.13","5.15.0-1011.14","5.15.0-1014.17","5.15.0-1015.18","5.15.0-1016.19","5.15.0-1017.20","5.15.0-1019.23","5.15.0-1020.25","5.15.0-1023.28","5.15.0-1024.29","5.15.0-1027.32","5.15.0-1028.33","5.15.0-1030.35","5.15.0-1031.36","5.15.0-1032.37","5.15.0-1033.38","5.15.0-1034.39","5.15.0-1035.40","5.15.0-1036.41","5.15.0-1037.42","5.15.0-1038.43","5.15.0-1039.44","5.15.0-1040.45","5.15.0-1041.46","5.15.0-1042.47","5.15.0-1044.49","5.15.0-1045.50","5.15.0-1046.51","5.15.0-1047.52","5.15.0-1048.53","5.15.0-1049.54","5.15.0-1050.55","5.15.0-1051.56","5.15.0-1052.57","5.15.0-1053.58","5.15.0-1054.59","5.15.0-1057.62","5.15.0-1058.63","5.15.0-1059.64","5.15.0-1060.66","5.15.0-1061.67","5.15.0-1062.68","5.15.0-1063.69","5.15.0-1064.70","5.15.0-1065.71","5.15.0-1066.72","5.15.0-1067.73","5.15.0-1068.74","5.15.0-1069.75"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gkeop","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1056.63"}]}],"versions":["5.15.0-1001.2","5.15.0-1002.4","5.15.0-1003.5","5.15.0-1004.6","5.15.0-1005.7","5.15.0-1007.10","5.15.0-1008.12","5.15.0-1011.15","5.15.0-1012.16","5.15.0-1013.17","5.15.0-1015.19","5.15.0-1016.21","5.15.0-1017.22","5.15.0-1018.23","5.15.0-1019.24","5.15.0-1020.25","5.15.0-1021.26","5.15.0-1022.27","5.15.0-1023.28","5.15.0-1024.29","5.15.0-1025.30","5.15.0-1026.31","5.15.0-1027.32","5.15.0-1028.33","5.15.0-1030.35","5.15.0-1031.37","5.15.0-1032.38","5.15.0-1033.39","5.15.0-1034.40","5.15.0-1035.41","5.15.0-1036.42","5.15.0-1037.43","5.15.0-1038.44","5.15.0-1039.45","5.15.0-1040.46","5.15.0-1043.50","5.15.0-1044.51","5.15.0-1045.52","5.15.0-1046.53","5.15.0-1047.54","5.15.0-1048.55","5.15.0-1049.56","5.15.0-1050.57","5.15.0-1051.58","5.15.0-1052.59","5.15.0-1053.60","5.15.0-1054.61","5.15.0-1055.62"]},{"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-45.45~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"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-ibm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1066.69"}]}],"versions":["5.15.0-1002.2","5.15.0-1003.3","5.15.0-1004.4","5.15.0-1005.5","5.15.0-1007.8","5.15.0-1009.11","5.15.0-1010.12","5.15.0-1012.14","5.15.0-1013.15","5.15.0-1015.17","5.15.0-1017.20","5.15.0-1018.21","5.15.0-1021.24","5.15.0-1022.25","5.15.0-1023.26","5.15.0-1025.28","5.15.0-1026.29","5.15.0-1027.30","5.15.0-1028.31","5.15.0-1029.32","5.15.0-1030.33","5.15.0-1031.34","5.15.0-1032.35","5.15.0-1033.36","5.15.0-1034.37","5.15.0-1035.38","5.15.0-1036.39","5.15.0-1037.40","5.15.0-1038.41","5.15.0-1040.43","5.15.0-1041.44","5.15.0-1042.45","5.15.0-1043.46","5.15.0-1044.47","5.15.0-1045.48","5.15.0-1046.49","5.15.0-1047.50","5.15.0-1048.51","5.15.0-1049.52","5.15.0-1050.53","5.15.0-1053.56","5.15.0-1054.57","5.15.0-1055.58","5.15.0-1056.59","5.15.0-1057.60","5.15.0-1058.61","5.15.0-1059.62","5.15.0-1060.63","5.15.0-1061.64","5.15.0-1062.65","5.15.0-1063.66","5.15.0-1064.67","5.15.0-1065.68"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-ibm-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1012.12~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"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-intel-iotg","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1071.77"}]}],"versions":["5.15.0-1004.6","5.15.0-1008.11","5.15.0-1010.14","5.15.0-1013.17","5.15.0-1015.20","5.15.0-1016.21","5.15.0-1017.22","5.15.0-1018.23","5.15.0-1021.26","5.15.0-1023.28","5.15.0-1025.30","5.15.0-1026.31","5.15.0-1027.32","5.15.0-1028.33","5.15.0-1030.35","5.15.0-1031.36","5.15.0-1033.38","5.15.0-1034.39","5.15.0-1035.40","5.15.0-1036.41","5.15.0-1037.42","5.15.0-1038.43","5.15.0-1039.45","5.15.0-1040.46","5.15.0-1043.49","5.15.0-1045.51","5.15.0-1046.52","5.15.0-1047.53","5.15.0-1048.54","5.15.0-1049.55","5.15.0-1050.56","5.15.0-1051.57","5.15.0-1052.58","5.15.0-1055.61","5.15.0-1057.63","5.15.0-1058.64","5.15.0-1059.65","5.15.0-1060.66","5.15.0-1061.67","5.15.0-1062.68","5.15.0-1063.69","5.15.0-1064.70","5.15.0-1065.71","5.15.0-1066.72","5.15.0-1067.73"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-kvm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1070.75"}]}],"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-1002.2","5.15.0-1004.4","5.15.0-1005.5","5.15.0-1007.7","5.15.0-1008.8","5.15.0-1010.11","5.15.0-1012.14","5.15.0-1013.16","5.15.0-1016.19","5.15.0-1017.21","5.15.0-1018.22","5.15.0-1019.23","5.15.0-1020.24","5.15.0-1021.26","5.15.0-1024.29","5.15.0-1025.30","5.15.0-1026.31","5.15.0-1028.33","5.15.0-1029.34","5.15.0-1030.35","5.15.0-1031.36","5.15.0-1032.37","5.15.0-1033.38","5.15.0-1034.39","5.15.0-1035.40","5.15.0-1037.42","5.15.0-1038.43","5.15.0-1039.44","5.15.0-1040.45","5.15.0-1041.46","5.15.0-1042.47","5.15.0-1044.49","5.15.0-1045.50","5.15.0-1046.51","5.15.0-1047.52","5.15.0-1048.53","5.15.0-1049.54","5.15.0-1050.55","5.15.0-1051.56","5.15.0-1052.57","5.15.0-1053.58","5.15.0-1054.59","5.15.0-1057.62","5.15.0-1058.63","5.15.0-1059.64","5.15.0-1060.65","5.15.0-1061.66","5.15.0-1062.67","5.15.0-1063.68","5.15.0-1064.69","5.15.0-1065.70","5.15.0-1066.71","5.15.0-1067.72","5.15.0-1068.73","5.15.0-1069.74"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-127.137"}]}],"versions":["5.15.0-22.22","5.15.0-23.23","5.15.0-24.24","5.15.0-27.28","5.15.0-30.31","5.15.0-33.34","5.15.0-35.36","5.15.0-37.39","5.15.0-39.42","5.15.0-40.43","5.15.0-41.44","5.15.0-43.46","5.15.0-46.49","5.15.0-47.53","5.15.0-48.54","5.15.0-50.56","5.15.0-52.58","5.15.0-53.59","5.15.0-56.62","5.15.0-57.63","5.15.0-58.64","5.15.0-60.66","5.15.0-67.74","5.15.0-69.76","5.15.0-70.77","5.15.0-71.78","5.15.0-72.79","5.15.0-73.80","5.15.0-75.82","5.15.0-76.83","5.15.0-78.85","5.15.0-79.88","5.15.0-82.91","5.15.0-83.92","5.15.0-84.93","5.15.0-86.95","5.15.0-87.96","5.15.0-88.98","5.15.0-89.99","5.15.0-91.101","5.15.0-92.102","5.15.0-94.104","5.15.0-97.107","5.15.0-100.110","5.15.0-101.111","5.15.0-102.112","5.15.0-105.115","5.15.0-106.116","5.15.0-107.117","5.15.0-110.120","5.15.0-113.123","5.15.0-116.126","5.15.0-117.127","5.15.0-118.128","5.15.0-119.129","5.15.0-121.131","5.15.0-122.132","5.15.0-124.134","5.15.0-125.135","5.15.0-126.136"]},{"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-44.44.1~22.04.1"}]}],"versions":["6.8.0-38.38.1~22.04.2","6.8.0-40.40.1~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1068.69"}]}],"versions":["5.15.0-1005.5","5.15.0-1007.7","5.15.0-1010.10","5.15.0-1015.15","5.15.0-1017.17","5.15.0-1018.18","5.15.0-1023.23","5.15.0-1025.25","5.15.0-1026.26","5.15.0-1027.27","5.15.0-1028.28","5.15.0-1029.29","5.15.0-1030.30","5.15.0-1031.31","5.15.0-1032.32","5.15.0-1033.33","5.15.0-1037.37","5.15.0-1039.39","5.15.0-1040.40","5.15.0-1041.41","5.15.0-1042.42","5.15.0-1043.43","5.15.0-1044.44","5.15.0-1045.45","5.15.0-1046.46","5.15.0-1047.47","5.15.0-1048.48","5.15.0-1053.54","5.15.0-1054.55","5.15.0-1055.56","5.15.0-1058.59","5.15.0-1059.60","5.15.0-1060.61","5.15.0-1061.62","5.15.0-1062.63","5.15.0-1063.64","5.15.0-1064.65","5.15.0-1065.66","5.15.0-1066.67","5.15.0-1067.68"]},{"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-1013.14~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"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-tegra","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1032.32"}]}],"versions":["5.15.0-1009.9","5.15.0-1010.10","5.15.0-1012.12","5.15.0-1013.13","5.15.0-1014.14","5.15.0-1015.15","5.15.0-1016.16","5.15.0-1017.17","5.15.0-1018.18","5.15.0-1019.19","5.15.0-1020.20","5.15.0-1021.21","5.15.0-1022.22","5.15.0-1025.25","5.15.0-1026.26","5.15.0-1027.27","5.15.0-1028.28","5.15.0-1030.30"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-tegra-igx","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1020.20"}]}],"versions":["5.15.0-1001.1","5.15.0-1002.2","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-1009.9","5.15.0-1012.12","5.15.0-1013.13","5.15.0-1015.15","5.15.0-1016.16","5.15.0-1018.18","5.15.0-1019.19"]},{"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","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1071.77"}]}],"versions":["5.13.0-1008.10","5.15.0-1001.3","5.15.0-1002.4","5.15.0-1003.5","5.15.0-1006.8","5.15.0-1007.9","5.15.0-1009.12","5.15.0-1011.15","5.15.0-1013.17","5.15.0-1016.20","5.15.0-1017.22","5.15.0-1018.23","5.15.0-1019.24","5.15.0-1021.27","5.15.0-1022.28","5.15.0-1025.31","5.15.0-1026.32","5.15.0-1027.33","5.15.0-1029.35","5.15.0-1030.36","5.15.0-1032.38","5.15.0-1033.39","5.15.0-1034.40","5.15.0-1035.41","5.15.0-1036.42","5.15.0-1037.43","5.15.0-1038.44","5.15.0-1039.45","5.15.0-1040.46","5.15.0-1041.47","5.15.0-1042.48","5.15.0-1044.50","5.15.0-1045.51","5.15.0-1046.52","5.15.0-1047.53","5.15.0-1048.54","5.15.0-1049.55","5.15.0-1050.56","5.15.0-1051.57","5.15.0-1052.58","5.15.0-1053.59","5.15.0-1054.60","5.15.0-1055.61","5.15.0-1058.64","5.15.0-1059.65","5.15.0-1060.66","5.15.0-1061.67","5.15.0-1062.68","5.15.0-1063.69","5.15.0-1064.70","5.15.0-1065.71","5.15.0-1066.72","5.15.0-1067.73","5.15.0-1068.74","5.15.0-1069.75","5.15.0-1070.76"]},{"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-1012.12~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"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-raspi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1066.69"}]}],"versions":["5.13.0-1008.9","5.15.0-1002.2","5.15.0-1003.3","5.15.0-1004.4","5.15.0-1005.5","5.15.0-1006.6","5.15.0-1008.8","5.15.0-1011.13","5.15.0-1012.14","5.15.0-1013.15","5.15.0-1014.16","5.15.0-1015.17","5.15.0-1016.18","5.15.0-1017.19","5.15.0-1018.20","5.15.0-1021.23","5.15.0-1022.24","5.15.0-1023.25","5.15.0-1024.26","5.15.0-1025.27","5.15.0-1026.28","5.15.0-1027.29","5.15.0-1028.30","5.15.0-1029.31","5.15.0-1030.32","5.15.0-1032.35","5.15.0-1033.36","5.15.0-1034.37","5.15.0-1035.38","5.15.0-1036.39","5.15.0-1037.40","5.15.0-1038.41","5.15.0-1040.43","5.15.0-1041.44","5.15.0-1042.45","5.15.0-1043.46","5.15.0-1044.47","5.15.0-1045.48","5.15.0-1046.49","5.15.0-1047.50","5.15.0-1048.51","5.15.0-1049.52","5.15.0-1050.53","5.15.0-1053.56","5.15.0-1054.57","5.15.0-1055.58","5.15.0-1058.61","5.15.0-1059.62","5.15.0-1060.63","5.15.0-1061.64","5.15.0-1062.65","5.15.0-1063.66","5.15.0-1064.67","5.15.0-1065.68"]},{"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-44.44.1~22.04.1"}]}],"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"]},{"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:22.04:LTS","package":"linux-xilinx-zynqmp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1039.43"}]}],"versions":["5.15.0-1022.26","5.15.0-1023.27","5.15.0-1025.29","5.15.0-1027.31","5.15.0-1030.34","5.15.0-1031.35","5.15.0-1035.39","5.15.0-1036.40","5.15.0-1037.41","5.15.0-1038.42"]},{"source":"osv","ecosystem":"Ubuntu:Nvidia-BlueField:22.04:LTS","package":"linux-bluefield","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1057.59"}]}],"versions":["5.15.0-1011.13","5.15.0-1014.16","5.15.0-1015.17","5.15.0-1017.19","5.15.0-1019.21","5.15.0-1021.23","5.15.0-1022.24","5.15.0-1023.25","5.15.0-1024.26","5.15.0-1027.29","5.15.0-1028.30","5.15.0-1031.33","5.15.0-1032.34","5.15.0-1033.35","5.15.0-1035.37","5.15.0-1036.38","5.15.0-1037.39","5.15.0-1038.40","5.15.0-1040.42","5.15.0-1042.44","5.15.0-1043.45","5.15.0-1044.46","5.15.0-1045.47","5.15.0-1047.49","5.15.0-1048.50","5.15.0-1050.52","5.15.0-1051.53","5.15.0-1052.54","5.15.0-1053.55","5.15.0-1054.56","5.15.0-1056.58"]},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:22.04:LTS","package":"linux-intel-iot-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1066.68"}]}],"versions":["5.15.0-1021.26","5.15.0-1022.27","5.15.0-1023.28","5.15.0-1024.29","5.15.0-1028.33","5.15.0-1033.35","5.15.0-1034.36","5.15.0-1035.37","5.15.0-1036.38","5.15.0-1037.39","5.15.0-1038.40","5.15.0-1039.41","5.15.0-1040.42","5.15.0-1041.43","5.15.0-1042.44","5.15.0-1043.45","5.15.0-1044.46","5.15.0-1046.48","5.15.0-1047.49","5.15.0-1048.50","5.15.0-1049.51","5.15.0-1050.52","5.15.0-1053.55","5.15.0-1054.56","5.15.0-1055.57","5.15.0-1056.58","5.15.0-1057.59","5.15.0-1058.60","5.15.0-1059.61","5.15.0-1060.62","5.15.0-1061.63","5.15.0-1063.65","5.15.0-1064.66"]},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:22.04:LTS","package":"linux-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1074.82"}]}],"versions":["5.15.0-1006.6","5.15.0-1007.7","5.15.0-1009.9","5.15.0-1011.11","5.15.0-1014.14","5.15.0-1015.15","5.15.0-1016.16","5.15.0-1019.19","5.15.0-1020.20","5.15.0-1021.21","5.15.0-1022.22","5.15.0-1024.25","5.15.0-1025.28","5.15.0-1028.31","5.15.0-1029.32","5.15.0-1030.33","5.15.0-1032.35","5.15.0-1033.36","5.15.0-1034.37","5.15.0-1036.39","5.15.0-1037.40","5.15.0-1038.41","5.15.0-1039.42","5.15.0-1040.45","5.15.0-1041.46","5.15.0-1042.47","5.15.0-1043.48","5.15.0-1044.49","5.15.0-1045.50","5.15.0-1046.52","5.15.0-1048.54","5.15.0-1049.55","5.15.0-1050.56","5.15.0-1051.57","5.15.0-1052.58","5.15.0-1053.59","5.15.0-1054.60","5.15.0-1055.62","5.15.0-1056.63","5.15.0-1057.64","5.15.0-1058.66","5.15.0-1061.69","5.15.0-1062.70","5.15.0-1063.71","5.15.0-1064.72","5.15.0-1065.73","5.15.0-1066.74","5.15.0-1067.75","5.15.0-1068.76","5.15.0-1069.77","5.15.0-1070.78","5.15.0-1071.79","5.15.0-1072.80","5.15.0-1073.81"]},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:22.04:LTS","package":"linux-realtime-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.1-1008.8~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"]},{"source":"osv","ecosystem":"Ubuntu:Pro:FIPS-preview:22.04:LTS","package":"linux-aws-fips","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1042.47+fips1","5.15.0-1051.56+fips1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:FIPS-preview:22.04:LTS","package":"linux-azure-fips","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1053.61+fips1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:FIPS-preview:22.04:LTS","package":"linux-fips","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-73.80+fips1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:FIPS-preview:22.04:LTS","package":"linux-gcp-fips","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1048.56+fips1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:FIPS-updates:22.04:LTS","package":"linux-aws-fips","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1073.79+fips1"}]}],"versions":["5.15.0-1051.56+fips1","5.15.0-1052.57+fips1","5.15.0-1053.58+fips1","5.15.0-1055.60+fips1","5.15.0-1056.61+fips1","5.15.0-1057.63+fips1","5.15.0-1060.66+fips1","5.15.0-1061.67+fips1","5.15.0-1062.68+fips1","5.15.0-1063.69+fips1","5.15.0-1064.70+fips1","5.15.0-1065.71+fips1","5.15.0-1066.72+fips1","5.15.0-1067.73+fips1","5.15.0-1068.74+fips1","5.15.0-1069.75+fips1","5.15.0-1070.76+fips1","5.15.0-1071.77+fips1","5.15.0-1072.78+fips1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:FIPS-updates:22.04:LTS","package":"linux-azure-fips","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1078.87+fips1"}]}],"versions":["5.15.0-1053.61+fips1","5.15.0-1058.66+fips1","5.15.0-1059.67+fips1","5.15.0-1060.69+fips1","5.15.0-1061.70+fips1","5.15.0-1063.72+fips1","5.15.0-1064.73+fips1","5.15.0-1065.74+fips1","5.15.0-1067.76+fips1","5.15.0-1068.77+fips1","5.15.0-1070.79+fips1","5.15.0-1071.80+fips1","5.15.0-1072.81+fips1","5.15.0-1073.82+fips1","5.15.0-1074.83+fips1","5.15.0-1075.84+fips1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:FIPS-updates:22.04:LTS","package":"linux-fips","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-127.137+fips1"}]}],"versions":["5.15.0-73.80+fips1","5.15.0-92.102+fips1","5.15.0-94.104+fips1","5.15.0-97.107+fips1","5.15.0-100.110+fips1","5.15.0-101.111+fips1","5.15.0-102.112+fips1","5.15.0-105.115+fips1","5.15.0-106.116+fips1","5.15.0-107.117+fips1","5.15.0-111.121+fips1","5.15.0-113.123+fips1","5.15.0-115.125+fips1","5.15.0-117.127+fips1","5.15.0-118.128+fips1","5.15.0-119.129+fips1","5.15.0-121.131+fips1","5.15.0-122.132+fips1","5.15.0-124.134+fips1","5.15.0-125.135+fips1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:FIPS-updates:22.04:LTS","package":"linux-gcp-fips","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1072.80+fips1"}]}],"versions":["5.15.0-1048.56+fips1","5.15.0-1055.63+fips2","5.15.0-1058.66+fips1","5.15.0-1059.67+fips1","5.15.0-1060.68+fips1","5.15.0-1062.70+fips1","5.15.0-1063.71+fips1","5.15.0-1064.72+fips1","5.15.0-1065.73+fips1","5.15.0-1066.74+fips1","5.15.0-1067.75+fips1","5.15.0-1068.76+fips1","5.15.0-1069.77+fips1","5.15.0-1070.78+fips1","5.15.0-1071.79+fips1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-44.44"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-aws","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1015.16"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1014.16"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1014.16"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gke","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1010.13"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-ibm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1012.12"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-44.44.1"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1013.14"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1013.14.1"}]}],"versions":["6.8.0-1009.9.1","6.8.0-1011.11.1","6.8.0-1012.12.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1012.12"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oracle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1012.12"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-raspi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1011.12"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-riscv","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-44.44.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"]},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-raspi-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-2010.10"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.1-1008.8"}]}],"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"]},{"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:26.04:LTS","package":"linux-vmware","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["7.0.0-1006.6"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-44.44"}]}],"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"],"bundled":220},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-aws","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1015.16"}]}],"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"],"bundled":220},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1014.16"}]}],"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"],"bundled":220},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gke","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1010.13"}]}],"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"],"bundled":220},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-ibm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1012.12"}]}],"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"],"bundled":220},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-44.44.1"}]}],"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"],"bundled":220},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1012.12"}]}],"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"],"bundled":220},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oracle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1012.12"}]}],"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"],"bundled":220},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-raspi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1011.12"}]}],"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"],"bundled":220},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1014.16"}]}],"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"],"bundled":221},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1013.14"}]}],"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"],"bundled":219},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-nvidia-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1013.14.1"}]}],"versions":["6.8.0-1009.9.1","6.8.0-1011.11.1","6.8.0-1012.12.1"],"bundled":219},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-1013.14~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"],"bundled":219},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-44.44.1~22.04.1"}]}],"versions":["6.8.0-38.38.1~22.04.2","6.8.0-40.40.1~22.04.1"],"bundled":222},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-hwe-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.8.0-45.45~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"],"bundled":227},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gcp-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1072.80~20.04.1"}]}],"versions":["5.15.0-1006.9~20.04.1","5.15.0-1012.17~20.04.1","5.15.0-1013.18~20.04.1","5.15.0-1016.21~20.04.1","5.15.0-1017.23~20.04.2","5.15.0-1018.24~20.04.1","5.15.0-1021.28~20.04.1","5.15.0-1022.29~20.04.1","5.15.0-1025.32~20.04.2","5.15.0-1026.33~20.04.1","5.15.0-1027.34~20.04.1","5.15.0-1029.36~20.04.1","5.15.0-1030.37~20.04.1","5.15.0-1031.38~20.04.1","5.15.0-1032.40~20.04.1","5.15.0-1033.41~20.04.1","5.15.0-1034.42~20.04.1","5.15.0-1035.43~20.04.1","5.15.0-1036.44~20.04.1","5.15.0-1037.45~20.04.1","5.15.0-1038.46~20.04.1","5.15.0-1039.47~20.04.1","5.15.0-1040.48~20.04.1","5.15.0-1041.49~20.04.1","5.15.0-1042.50~20.04.1","5.15.0-1044.52~20.04.1","5.15.0-1045.53~20.04.2","5.15.0-1046.54~20.04.1","5.15.0-1047.55~20.04.1","5.15.0-1048.56~20.04.1","5.15.0-1049.57~20.04.1","5.15.0-1051.59~20.04.1","5.15.0-1052.60~20.04.1","5.15.0-1053.61~20.04.1","5.15.0-1054.62~20.04.1","5.15.0-1055.63~20.04.1","5.15.0-1058.66~20.04.1","5.15.0-1059.67~20.04.1","5.15.0-1060.68~20.04.1","5.15.0-1062.70~20.04.1","5.15.0-1065.73~20.04.1","5.15.0-1066.74~20.04.1","5.15.0-1067.75~20.04.1","5.15.0-1068.76~20.04.1","5.15.0-1069.77~20.04.1","5.15.0-1070.78~20.04.1","5.15.0-1071.79~20.04.1"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-ibm-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1066.69~20.04.1"}]}],"versions":["5.15.0-1033.36~20.04.1","5.15.0-1034.37~20.04.1","5.15.0-1035.38~20.04.1","5.15.0-1036.39~20.04.1","5.15.0-1037.40~20.04.1","5.15.0-1038.41~20.04.1","5.15.0-1040.43~20.04.1","5.15.0-1041.44~20.04.1","5.15.0-1042.45~20.04.1","5.15.0-1043.46~20.04.1","5.15.0-1044.47~20.04.1","5.15.0-1045.48~20.04.1","5.15.0-1046.49~20.04.1","5.15.0-1047.50~20.04.1","5.15.0-1048.51~20.04.1","5.15.0-1049.52~20.04.1","5.15.0-1050.53~20.04.1","5.15.0-1053.56~20.04.1","5.15.0-1054.57~20.04.1","5.15.0-1055.58~20.04.1","5.15.0-1057.60~20.04.1","5.15.0-1058.61~20.04.1","5.15.0-1059.62~20.04.1","5.15.0-1060.63~20.04.1","5.15.0-1061.64~20.04.1","5.15.0-1062.65~20.04.1","5.15.0-1063.66~20.04.1","5.15.0-1064.67~20.04.1","5.15.0-1065.68~20.04.1"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-lowlatency-hwe-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-127.137~20.04.1"}]}],"versions":["5.15.0-33.34~20.04.1","5.15.0-42.45~20.04.1","5.15.0-43.46~20.04.1","5.15.0-46.49~20.04.1","5.15.0-48.54~20.04.1","5.15.0-50.56~20.04.1","5.15.0-52.58~20.04.1","5.15.0-53.59~20.04.1","5.15.0-56.62~20.04.1","5.15.0-58.64~20.04.1","5.15.0-60.66~20.04.1","5.15.0-67.74~20.04.1","5.15.0-69.76~20.04.1","5.15.0-70.77~20.04.1","5.15.0-71.78~20.04.1","5.15.0-72.79~20.04.1","5.15.0-73.80~20.04.1","5.15.0-75.82~20.04.1","5.15.0-76.83~20.04.1","5.15.0-78.85~20.04.1","5.15.0-79.88~20.04.1","5.15.0-82.91~20.04.1","5.15.0-83.92~20.04.1","5.15.0-84.93~20.04.1","5.15.0-86.95~20.04.1","5.15.0-87.96~20.04.1","5.15.0-88.98~20.04.1","5.15.0-89.99~20.04.1","5.15.0-91.101~20.04.1","5.15.0-92.102~20.04.1","5.15.0-94.104~20.04.1","5.15.0-97.107~20.04.1","5.15.0-100.110~20.04.1","5.15.0-101.111~20.04.1","5.15.0-102.112~20.04.1","5.15.0-105.115~20.04.1","5.15.0-106.116~20.04.1","5.15.0-107.117~20.04.1","5.15.0-110.120~20.04.1","5.15.0-113.123~20.04.1","5.15.0-116.126~20.04.1","5.15.0-117.127~20.04.1","5.15.0-118.128~20.04.1","5.15.0-119.129~20.04.1","5.15.0-121.131~20.04.1","5.15.0-122.132~20.04.1","5.15.0-124.134~20.04.1","5.15.0-125.135~20.04.1","5.15.0-126.136~20.04.1"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oracle-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1071.77~20.04.1"}]}],"versions":["5.15.0-1007.9~20.04.1","5.15.0-1013.17~20.04.1","5.15.0-1016.20~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-1021.27~20.04.1","5.15.0-1022.28~20.04.1","5.15.0-1025.31~20.04.2","5.15.0-1027.33~20.04.1","5.15.0-1029.35~20.04.1","5.15.0-1030.36~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-1041.47~20.04.1","5.15.0-1042.48~20.04.1","5.15.0-1044.50~20.04.1","5.15.0-1045.51~20.04.1","5.15.0-1046.52~20.04.1","5.15.0-1047.53~20.04.1","5.15.0-1048.54~20.04.1","5.15.0-1049.55~20.04.1","5.15.0-1050.56~20.04.1","5.15.0-1051.57~20.04.1","5.15.0-1052.58~20.04.1","5.15.0-1053.59~20.04.1","5.15.0-1054.60~20.04.1","5.15.0-1055.61~20.04.1","5.15.0-1058.64~20.04.1","5.15.0-1059.65~20.04.1","5.15.0-1061.67~20.04.1","5.15.0-1062.68~20.04.1","5.15.0-1063.69~20.04.1","5.15.0-1065.71~20.04.1","5.15.0-1066.72~20.04.1","5.15.0-1067.73~20.04.1","5.15.0-1068.74~20.04.1","5.15.0-1069.75~20.04.1","5.15.0-1070.76~20.04.1"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-127.137"}]}],"versions":["5.13.0-19.19","5.15.0-17.17","5.15.0-18.18","5.15.0-22.22","5.15.0-23.23","5.15.0-25.25","5.15.0-27.28","5.15.0-30.31","5.15.0-33.34","5.15.0-35.36","5.15.0-37.39","5.15.0-39.42","5.15.0-40.43","5.15.0-41.44","5.15.0-43.46","5.15.0-46.49","5.15.0-47.51","5.15.0-48.54","5.15.0-50.56","5.15.0-52.58","5.15.0-53.59","5.15.0-56.62","5.15.0-57.63","5.15.0-58.64","5.15.0-60.66","5.15.0-67.74","5.15.0-69.76","5.15.0-70.77","5.15.0-71.78","5.15.0-72.79","5.15.0-73.80","5.15.0-75.82","5.15.0-76.83","5.15.0-78.85","5.15.0-79.86","5.15.0-82.91","5.15.0-83.92","5.15.0-84.93","5.15.0-86.96","5.15.0-87.97","5.15.0-88.98","5.15.0-89.99","5.15.0-91.101","5.15.0-92.102","5.15.0-94.104","5.15.0-97.107","5.15.0-100.110","5.15.0-101.111","5.15.0-102.112","5.15.0-105.115","5.15.0-106.116","5.15.0-107.117","5.15.0-112.122","5.15.0-113.123","5.15.0-116.126","5.15.0-117.127","5.15.0-118.128","5.15.0-119.129","5.15.0-121.131","5.15.0-122.132","5.15.0-124.134","5.15.0-125.135","5.15.0-126.136"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1072.80"}]}],"versions":["5.13.0-1005.6","5.15.0-1001.3","5.15.0-1002.5","5.15.0-1003.6","5.15.0-1004.7","5.15.0-1005.8","5.15.0-1006.9","5.15.0-1008.12","5.15.0-1010.15","5.15.0-1013.18","5.15.0-1016.21","5.15.0-1017.23","5.15.0-1018.24","5.15.0-1019.25","5.15.0-1021.28","5.15.0-1022.29","5.15.0-1025.32","5.15.0-1026.33","5.15.0-1027.34","5.15.0-1029.36","5.15.0-1030.37","5.15.0-1031.38","5.15.0-1032.40","5.15.0-1034.42","5.15.0-1035.43","5.15.0-1036.44","5.15.0-1037.45","5.15.0-1038.46","5.15.0-1039.47","5.15.0-1040.48","5.15.0-1041.49","5.15.0-1042.50","5.15.0-1044.52","5.15.0-1045.53","5.15.0-1046.54","5.15.0-1047.55","5.15.0-1048.56","5.15.0-1049.57","5.15.0-1051.59","5.15.0-1052.60","5.15.0-1053.61","5.15.0-1054.62","5.15.0-1055.63","5.15.0-1058.66","5.15.0-1059.67","5.15.0-1060.68","5.15.0-1062.70","5.15.0-1063.71","5.15.0-1064.72","5.15.0-1065.73","5.15.0-1066.74","5.15.0-1067.75","5.15.0-1068.76","5.15.0-1069.77","5.15.0-1070.78","5.15.0-1071.79"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gke","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1070.76"}]}],"versions":["5.15.0-1002.2","5.15.0-1003.3","5.15.0-1004.5","5.15.0-1005.6","5.15.0-1006.7","5.15.0-1008.10","5.15.0-1010.13","5.15.0-1011.14","5.15.0-1014.17","5.15.0-1015.18","5.15.0-1016.19","5.15.0-1017.20","5.15.0-1019.23","5.15.0-1020.25","5.15.0-1023.28","5.15.0-1024.29","5.15.0-1027.32","5.15.0-1028.33","5.15.0-1030.35","5.15.0-1031.36","5.15.0-1032.37","5.15.0-1033.38","5.15.0-1034.39","5.15.0-1035.40","5.15.0-1036.41","5.15.0-1037.42","5.15.0-1038.43","5.15.0-1039.44","5.15.0-1040.45","5.15.0-1041.46","5.15.0-1042.47","5.15.0-1044.49","5.15.0-1045.50","5.15.0-1046.51","5.15.0-1047.52","5.15.0-1048.53","5.15.0-1049.54","5.15.0-1050.55","5.15.0-1051.56","5.15.0-1052.57","5.15.0-1053.58","5.15.0-1054.59","5.15.0-1057.62","5.15.0-1058.63","5.15.0-1059.64","5.15.0-1060.66","5.15.0-1061.67","5.15.0-1062.68","5.15.0-1063.69","5.15.0-1064.70","5.15.0-1065.71","5.15.0-1066.72","5.15.0-1067.73","5.15.0-1068.74","5.15.0-1069.75"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gkeop","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1056.63"}]}],"versions":["5.15.0-1001.2","5.15.0-1002.4","5.15.0-1003.5","5.15.0-1004.6","5.15.0-1005.7","5.15.0-1007.10","5.15.0-1008.12","5.15.0-1011.15","5.15.0-1012.16","5.15.0-1013.17","5.15.0-1015.19","5.15.0-1016.21","5.15.0-1017.22","5.15.0-1018.23","5.15.0-1019.24","5.15.0-1020.25","5.15.0-1021.26","5.15.0-1022.27","5.15.0-1023.28","5.15.0-1024.29","5.15.0-1025.30","5.15.0-1026.31","5.15.0-1027.32","5.15.0-1028.33","5.15.0-1030.35","5.15.0-1031.37","5.15.0-1032.38","5.15.0-1033.39","5.15.0-1034.40","5.15.0-1035.41","5.15.0-1036.42","5.15.0-1037.43","5.15.0-1038.44","5.15.0-1039.45","5.15.0-1040.46","5.15.0-1043.50","5.15.0-1044.51","5.15.0-1045.52","5.15.0-1046.53","5.15.0-1047.54","5.15.0-1048.55","5.15.0-1049.56","5.15.0-1050.57","5.15.0-1051.58","5.15.0-1052.59","5.15.0-1053.60","5.15.0-1054.61","5.15.0-1055.62"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-ibm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1066.69"}]}],"versions":["5.15.0-1002.2","5.15.0-1003.3","5.15.0-1004.4","5.15.0-1005.5","5.15.0-1007.8","5.15.0-1009.11","5.15.0-1010.12","5.15.0-1012.14","5.15.0-1013.15","5.15.0-1015.17","5.15.0-1017.20","5.15.0-1018.21","5.15.0-1021.24","5.15.0-1022.25","5.15.0-1023.26","5.15.0-1025.28","5.15.0-1026.29","5.15.0-1027.30","5.15.0-1028.31","5.15.0-1029.32","5.15.0-1030.33","5.15.0-1031.34","5.15.0-1032.35","5.15.0-1033.36","5.15.0-1034.37","5.15.0-1035.38","5.15.0-1036.39","5.15.0-1037.40","5.15.0-1038.41","5.15.0-1040.43","5.15.0-1041.44","5.15.0-1042.45","5.15.0-1043.46","5.15.0-1044.47","5.15.0-1045.48","5.15.0-1046.49","5.15.0-1047.50","5.15.0-1048.51","5.15.0-1049.52","5.15.0-1050.53","5.15.0-1053.56","5.15.0-1054.57","5.15.0-1055.58","5.15.0-1056.59","5.15.0-1057.60","5.15.0-1058.61","5.15.0-1059.62","5.15.0-1060.63","5.15.0-1061.64","5.15.0-1062.65","5.15.0-1063.66","5.15.0-1064.67","5.15.0-1065.68"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-kvm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1070.75"}]}],"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-1002.2","5.15.0-1004.4","5.15.0-1005.5","5.15.0-1007.7","5.15.0-1008.8","5.15.0-1010.11","5.15.0-1012.14","5.15.0-1013.16","5.15.0-1016.19","5.15.0-1017.21","5.15.0-1018.22","5.15.0-1019.23","5.15.0-1020.24","5.15.0-1021.26","5.15.0-1024.29","5.15.0-1025.30","5.15.0-1026.31","5.15.0-1028.33","5.15.0-1029.34","5.15.0-1030.35","5.15.0-1031.36","5.15.0-1032.37","5.15.0-1033.38","5.15.0-1034.39","5.15.0-1035.40","5.15.0-1037.42","5.15.0-1038.43","5.15.0-1039.44","5.15.0-1040.45","5.15.0-1041.46","5.15.0-1042.47","5.15.0-1044.49","5.15.0-1045.50","5.15.0-1046.51","5.15.0-1047.52","5.15.0-1048.53","5.15.0-1049.54","5.15.0-1050.55","5.15.0-1051.56","5.15.0-1052.57","5.15.0-1053.58","5.15.0-1054.59","5.15.0-1057.62","5.15.0-1058.63","5.15.0-1059.64","5.15.0-1060.65","5.15.0-1061.66","5.15.0-1062.67","5.15.0-1063.68","5.15.0-1064.69","5.15.0-1065.70","5.15.0-1066.71","5.15.0-1067.72","5.15.0-1068.73","5.15.0-1069.74"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-127.137"}]}],"versions":["5.15.0-22.22","5.15.0-23.23","5.15.0-24.24","5.15.0-27.28","5.15.0-30.31","5.15.0-33.34","5.15.0-35.36","5.15.0-37.39","5.15.0-39.42","5.15.0-40.43","5.15.0-41.44","5.15.0-43.46","5.15.0-46.49","5.15.0-47.53","5.15.0-48.54","5.15.0-50.56","5.15.0-52.58","5.15.0-53.59","5.15.0-56.62","5.15.0-57.63","5.15.0-58.64","5.15.0-60.66","5.15.0-67.74","5.15.0-69.76","5.15.0-70.77","5.15.0-71.78","5.15.0-72.79","5.15.0-73.80","5.15.0-75.82","5.15.0-76.83","5.15.0-78.85","5.15.0-79.88","5.15.0-82.91","5.15.0-83.92","5.15.0-84.93","5.15.0-86.95","5.15.0-87.96","5.15.0-88.98","5.15.0-89.99","5.15.0-91.101","5.15.0-92.102","5.15.0-94.104","5.15.0-97.107","5.15.0-100.110","5.15.0-101.111","5.15.0-102.112","5.15.0-105.115","5.15.0-106.116","5.15.0-107.117","5.15.0-110.120","5.15.0-113.123","5.15.0-116.126","5.15.0-117.127","5.15.0-118.128","5.15.0-119.129","5.15.0-121.131","5.15.0-122.132","5.15.0-124.134","5.15.0-125.135","5.15.0-126.136"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-nvidia","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1068.69"}]}],"versions":["5.15.0-1005.5","5.15.0-1007.7","5.15.0-1010.10","5.15.0-1015.15","5.15.0-1017.17","5.15.0-1018.18","5.15.0-1023.23","5.15.0-1025.25","5.15.0-1026.26","5.15.0-1027.27","5.15.0-1028.28","5.15.0-1029.29","5.15.0-1030.30","5.15.0-1031.31","5.15.0-1032.32","5.15.0-1033.33","5.15.0-1037.37","5.15.0-1039.39","5.15.0-1040.40","5.15.0-1041.41","5.15.0-1042.42","5.15.0-1043.43","5.15.0-1044.44","5.15.0-1045.45","5.15.0-1046.46","5.15.0-1047.47","5.15.0-1048.48","5.15.0-1053.54","5.15.0-1054.55","5.15.0-1055.56","5.15.0-1058.59","5.15.0-1059.60","5.15.0-1060.61","5.15.0-1061.62","5.15.0-1062.63","5.15.0-1063.64","5.15.0-1064.65","5.15.0-1065.66","5.15.0-1066.67","5.15.0-1067.68"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oracle","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1071.77"}]}],"versions":["5.13.0-1008.10","5.15.0-1001.3","5.15.0-1002.4","5.15.0-1003.5","5.15.0-1006.8","5.15.0-1007.9","5.15.0-1009.12","5.15.0-1011.15","5.15.0-1013.17","5.15.0-1016.20","5.15.0-1017.22","5.15.0-1018.23","5.15.0-1019.24","5.15.0-1021.27","5.15.0-1022.28","5.15.0-1025.31","5.15.0-1026.32","5.15.0-1027.33","5.15.0-1029.35","5.15.0-1030.36","5.15.0-1032.38","5.15.0-1033.39","5.15.0-1034.40","5.15.0-1035.41","5.15.0-1036.42","5.15.0-1037.43","5.15.0-1038.44","5.15.0-1039.45","5.15.0-1040.46","5.15.0-1041.47","5.15.0-1042.48","5.15.0-1044.50","5.15.0-1045.51","5.15.0-1046.52","5.15.0-1047.53","5.15.0-1048.54","5.15.0-1049.55","5.15.0-1050.56","5.15.0-1051.57","5.15.0-1052.58","5.15.0-1053.59","5.15.0-1054.60","5.15.0-1055.61","5.15.0-1058.64","5.15.0-1059.65","5.15.0-1060.66","5.15.0-1061.67","5.15.0-1062.68","5.15.0-1063.69","5.15.0-1064.70","5.15.0-1065.71","5.15.0-1066.72","5.15.0-1067.73","5.15.0-1068.74","5.15.0-1069.75","5.15.0-1070.76"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-raspi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1066.69"}]}],"versions":["5.13.0-1008.9","5.15.0-1002.2","5.15.0-1003.3","5.15.0-1004.4","5.15.0-1005.5","5.15.0-1006.6","5.15.0-1008.8","5.15.0-1011.13","5.15.0-1012.14","5.15.0-1013.15","5.15.0-1014.16","5.15.0-1015.17","5.15.0-1016.18","5.15.0-1017.19","5.15.0-1018.20","5.15.0-1021.23","5.15.0-1022.24","5.15.0-1023.25","5.15.0-1024.26","5.15.0-1025.27","5.15.0-1026.28","5.15.0-1027.29","5.15.0-1028.30","5.15.0-1029.31","5.15.0-1030.32","5.15.0-1032.35","5.15.0-1033.36","5.15.0-1034.37","5.15.0-1035.38","5.15.0-1036.39","5.15.0-1037.40","5.15.0-1038.41","5.15.0-1040.43","5.15.0-1041.44","5.15.0-1042.45","5.15.0-1043.46","5.15.0-1044.47","5.15.0-1045.48","5.15.0-1046.49","5.15.0-1047.50","5.15.0-1048.51","5.15.0-1049.52","5.15.0-1050.53","5.15.0-1053.56","5.15.0-1054.57","5.15.0-1055.58","5.15.0-1058.61","5.15.0-1059.62","5.15.0-1060.63","5.15.0-1061.64","5.15.0-1062.65","5.15.0-1063.66","5.15.0-1064.67","5.15.0-1065.68"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-aws-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1073.79~20.04.1"}]}],"versions":["5.15.0-1014.18~20.04.1","5.15.0-1015.19~20.04.1","5.15.0-1017.21~20.04.1","5.15.0-1019.23~20.04.1","5.15.0-1020.24~20.04.1","5.15.0-1021.25~20.04.1","5.15.0-1022.26~20.04.1","5.15.0-1023.27~20.04.1","5.15.0-1026.30~20.04.2","5.15.0-1027.31~20.04.1","5.15.0-1028.32~20.04.1","5.15.0-1030.34~20.04.1","5.15.0-1031.35~20.04.1","5.15.0-1033.37~20.04.1","5.15.0-1034.38~20.04.1","5.15.0-1035.39~20.04.1","5.15.0-1036.40~20.04.1","5.15.0-1037.41~20.04.1","5.15.0-1038.43~20.04.1","5.15.0-1039.44~20.04.1","5.15.0-1040.45~20.04.1","5.15.0-1041.46~20.04.1","5.15.0-1043.48~20.04.1","5.15.0-1044.49~20.04.1","5.15.0-1045.50~20.04.1","5.15.0-1047.52~20.04.1","5.15.0-1048.53~20.04.1","5.15.0-1049.54~20.04.1","5.15.0-1050.55~20.04.1","5.15.0-1051.56~20.04.1","5.15.0-1052.57~20.04.1","5.15.0-1053.58~20.04.1","5.15.0-1055.60~20.04.1","5.15.0-1056.61~20.04.1","5.15.0-1057.63~20.04.1","5.15.0-1058.64~20.04.1","5.15.0-1061.67~20.04.1","5.15.0-1062.68~20.04.1","5.15.0-1063.69~20.04.1","5.15.0-1064.70~20.04.1","5.15.0-1065.71~20.04.1","5.15.0-1066.72~20.04.1","5.15.0-1067.73~20.04.1","5.15.0-1068.74~20.04.1","5.15.0-1069.75~20.04.1","5.15.0-1070.76~20.04.1","5.15.0-1071.77~20.04.1","5.15.0-1072.78~20.04.1"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1073.79"}]}],"versions":["5.13.0-1005.6","5.15.0-1002.4","5.15.0-1003.5","5.15.0-1004.6","5.15.0-1005.7","5.15.0-1008.10","5.15.0-1009.11","5.15.0-1011.14","5.15.0-1013.17","5.15.0-1014.18","5.15.0-1015.19","5.15.0-1017.21","5.15.0-1019.23","5.15.0-1020.24","5.15.0-1021.25","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","5.15.0-1030.34","5.15.0-1031.35","5.15.0-1033.37","5.15.0-1034.38","5.15.0-1035.39","5.15.0-1036.40","5.15.0-1037.41","5.15.0-1038.43","5.15.0-1039.44","5.15.0-1040.45","5.15.0-1042.47","5.15.0-1043.48","5.15.0-1044.49","5.15.0-1045.50","5.15.0-1047.52","5.15.0-1048.53","5.15.0-1049.54","5.15.0-1050.55","5.15.0-1051.56","5.15.0-1052.57","5.15.0-1053.58","5.15.0-1055.60","5.15.0-1056.61","5.15.0-1057.63","5.15.0-1060.66","5.15.0-1061.67","5.15.0-1062.68","5.15.0-1063.69","5.15.0-1064.70","5.15.0-1065.71","5.15.0-1066.72","5.15.0-1067.73","5.15.0-1068.74","5.15.0-1069.75","5.15.0-1070.76","5.15.0-1071.77","5.15.0-1072.78"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-hwe-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-127.137~20.04.1"}]}],"versions":["5.15.0-33.34~20.04.1","5.15.0-41.44~20.04.1","5.15.0-43.46~20.04.1","5.15.0-46.49~20.04.1","5.15.0-48.54~20.04.1","5.15.0-50.56~20.04.1","5.15.0-52.58~20.04.1","5.15.0-53.59~20.04.1","5.15.0-56.62~20.04.1","5.15.0-57.63~20.04.1","5.15.0-58.64~20.04.1","5.15.0-60.66~20.04.1","5.15.0-67.74~20.04.1","5.15.0-69.76~20.04.1","5.15.0-70.77~20.04.1","5.15.0-71.78~20.04.1","5.15.0-72.79~20.04.1","5.15.0-73.80~20.04.1","5.15.0-75.82~20.04.1","5.15.0-76.83~20.04.1","5.15.0-78.85~20.04.1","5.15.0-79.86~20.04.2","5.15.0-82.91~20.04.1","5.15.0-83.92~20.04.1","5.15.0-84.93~20.04.1","5.15.0-86.96~20.04.1","5.15.0-87.97~20.04.1","5.15.0-88.98~20.04.1","5.15.0-89.99~20.04.1","5.15.0-91.101~20.04.1","5.15.0-92.102~20.04.1","5.15.0-94.104~20.04.1","5.15.0-97.107~20.04.1","5.15.0-100.110~20.04.1","5.15.0-101.111~20.04.1","5.15.0-102.112~20.04.1","5.15.0-105.115~20.04.1","5.15.0-106.116~20.04.1","5.15.0-107.117~20.04.1","5.15.0-113.123~20.04.1","5.15.0-116.126~20.04.1","5.15.0-117.127~20.04.1","5.15.0-118.128~20.04.1","5.15.0-119.129~20.04.1","5.15.0-121.131~20.04.1","5.15.0-122.132~20.04.1","5.15.0-124.134~20.04.1","5.15.0-125.135~20.04.1","5.15.0-126.136~20.04.1"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-xilinx-zynqmp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1039.43"}]}],"versions":["5.15.0-1022.26","5.15.0-1023.27","5.15.0-1025.29","5.15.0-1027.31","5.15.0-1030.34","5.15.0-1031.35","5.15.0-1035.39","5.15.0-1036.40","5.15.0-1037.41","5.15.0-1038.42"],"bundled":167},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-intel-iotg","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1071.77"}]}],"versions":["5.15.0-1004.6","5.15.0-1008.11","5.15.0-1010.14","5.15.0-1013.17","5.15.0-1015.20","5.15.0-1016.21","5.15.0-1017.22","5.15.0-1018.23","5.15.0-1021.26","5.15.0-1023.28","5.15.0-1025.30","5.15.0-1026.31","5.15.0-1027.32","5.15.0-1028.33","5.15.0-1030.35","5.15.0-1031.36","5.15.0-1033.38","5.15.0-1034.39","5.15.0-1035.40","5.15.0-1036.41","5.15.0-1037.42","5.15.0-1038.43","5.15.0-1039.45","5.15.0-1040.46","5.15.0-1043.49","5.15.0-1045.51","5.15.0-1046.52","5.15.0-1047.53","5.15.0-1048.54","5.15.0-1049.55","5.15.0-1050.56","5.15.0-1051.57","5.15.0-1052.58","5.15.0-1055.61","5.15.0-1057.63","5.15.0-1058.64","5.15.0-1059.65","5.15.0-1060.66","5.15.0-1061.67","5.15.0-1062.68","5.15.0-1063.69","5.15.0-1064.70","5.15.0-1065.71","5.15.0-1066.72","5.15.0-1067.73"],"bundled":181},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-intel-iotg-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1071.77~20.04.1"}]}],"versions":["5.15.0-1003.5~20.04.1","5.15.0-1008.11~20.04.1","5.15.0-1010.14~20.04.1","5.15.0-1015.20~20.04.2","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-1021.26~20.04.1","5.15.0-1023.28~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-1030.35~20.04.1","5.15.0-1031.36~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-1040.46~20.04.1","5.15.0-1043.49~20.04.1","5.15.0-1045.51~20.04.1","5.15.0-1046.52~20.04.1","5.15.0-1048.54~20.04.1","5.15.0-1049.55~20.04.1","5.15.0-1050.56~20.04.1","5.15.0-1051.57~20.04.1","5.15.0-1052.58~20.04.1","5.15.0-1055.61~20.04.1","5.15.0-1058.64~20.04.1","5.15.0-1059.65~20.04.1","5.15.0-1060.66~20.04.1","5.15.0-1061.67~20.04.1","5.15.0-1062.68~20.04.1","5.15.0-1063.69~20.04.1","5.15.0-1064.70~20.04.1","5.15.0-1065.71~20.04.1","5.15.0-1066.72~20.04.1","5.15.0-1067.73~20.04.1"],"bundled":181},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1078.87"}]}],"versions":["5.13.0-1006.7","5.15.0-1001.2","5.15.0-1002.3","5.15.0-1003.4","5.15.0-1005.6","5.15.0-1007.8","5.15.0-1008.9","5.15.0-1010.12","5.15.0-1012.15","5.15.0-1013.16","5.15.0-1014.17","5.15.0-1017.20","5.15.0-1019.24","5.15.0-1020.25","5.15.0-1021.26","5.15.0-1022.27","5.15.0-1023.29","5.15.0-1024.30","5.15.0-1029.36","5.15.0-1030.37","5.15.0-1031.38","5.15.0-1033.40","5.15.0-1034.41","5.15.0-1035.42","5.15.0-1036.43","5.15.0-1037.44","5.15.0-1038.45","5.15.0-1039.46","5.15.0-1040.47","5.15.0-1041.48","5.15.0-1042.49","5.15.0-1044.51","5.15.0-1045.52","5.15.0-1046.53","5.15.0-1047.54","5.15.0-1049.56","5.15.0-1050.57","5.15.0-1051.59","5.15.0-1052.60","5.15.0-1053.61","5.15.0-1054.62","5.15.0-1056.64","5.15.0-1057.65","5.15.0-1058.66","5.15.0-1059.67","5.15.0-1060.69","5.15.0-1061.70","5.15.0-1063.72","5.15.0-1064.73","5.15.0-1066.75","5.15.0-1067.76","5.15.0-1068.77","5.15.0-1070.79","5.15.0-1071.80","5.15.0-1072.81","5.15.0-1073.82","5.15.0-1074.83","5.15.0-1075.84"],"bundled":181},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.15.0-1078.87~20.04.1"}]}],"versions":["5.15.0-1007.8~20.04.1","5.15.0-1008.9~20.04.1","5.15.0-1013.16~20.04.1","5.15.0-1014.17~20.04.1","5.15.0-1017.20~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.29~20.04.1","5.15.0-1029.36~20.04.1","5.15.0-1030.37~20.04.1","5.15.0-1031.38~20.04.1","5.15.0-1033.40~20.04.1","5.15.0-1034.41~20.04.1","5.15.0-1035.42~20.04.1","5.15.0-1036.43~20.04.1","5.15.0-1037.44~20.04.1","5.15.0-1038.45~20.04.1","5.15.0-1039.46~20.04.1","5.15.0-1040.47~20.04.1","5.15.0-1041.48~20.04.1","5.15.0-1042.49~20.04.1","5.15.0-1043.50~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-1049.56~20.04.1","5.15.0-1050.57~20.04.1","5.15.0-1051.59~20.04.1","5.15.0-1052.60~20.04.1","5.15.0-1053.61~20.04.1","5.15.0-1054.62~20.04.1","5.15.0-1056.64~20.04.1","5.15.0-1057.65~20.04.1","5.15.0-1058.66~20.04.2","5.15.0-1059.67~20.04.1","5.15.0-1060.69~20.04.1","5.15.0-1061.70~20.04.1","5.15.0-1063.72~20.04.1","5.15.0-1064.73~20.04.1","5.15.0-1065.74~20.04.1","5.15.0-1067.76~20.04.1","5.15.0-1068.77~20.04.1","5.15.0-1070.79~20.04.1","5.15.0-1071.80~20.04.1","5.15.0-1072.81~20.04.1","5.15.0-1073.82~20.04.1","5.15.0-1074.83~20.04.1","5.15.0-1075.84~20.04.1"],"bundled":407}],"products":[{"vendor":"linux","product":"linux"},{"vendor":"linux","product":"linux_kernel"}],"references":[{"url":"https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e","tags":["x_transferred","Patch","web"]},{"url":"https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44","tags":["x_transferred","Patch","web"]},{"url":"https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80","tags":["x_transferred","Mailing List","Patch","web"]},{"url":"https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af","tags":["x_transferred","Patch","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38667","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-cqg5-mcpx-q78p"},{"url":"https://docs.bell-sw.com/security/cves/CVE-2024-38667","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/38xxx/CVE-2024-38667.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-38667","tags":["advisory"]},{"url":"https://advisories.mageia.org/MGASA-2024-0263.html","tags":["advisory"]},{"url":"https://bugs.mageia.org/show_bug.cgi?id=33373","tags":["report"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.37","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.36","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.35","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.34","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.33","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.32","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.31","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.30","tags":["web"]},{"url":"https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.29","tags":["web"]},{"url":"https://advisories.mageia.org/MGASA-2024-0266.html","tags":["advisory"]},{"url":"https://bugs.mageia.org/show_bug.cgi?id=33374","tags":["report"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2321","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48916","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48952","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52917","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52918","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35878","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35990","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36286","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38605","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38635","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42152","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42301","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42315","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43841","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43858","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43867","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43871","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43894","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45009","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46675","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46689","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46722","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46724","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46757","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46802","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46830","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46853","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47667","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47669","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47684","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47685","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47692","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47695","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47698","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47709","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47710","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47720","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47735","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47737","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47757","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49866","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49867","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49868","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49875","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49892","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49894","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49895","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49900","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49902","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49903","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49911","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49927","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49959","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49965","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49966","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49969","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49974","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49985","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50025","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50036","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50046","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50049","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2322","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48988","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52919","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2324","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48946","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48967","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48973","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48977","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48986","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48991","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48994","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49006","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49007","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49019","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49029","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49030","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49033","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52754","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52855","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26917","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41015","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50007","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2802","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38381","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38584","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38615","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38633","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38659","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40902","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40904","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41079","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42101","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42102","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42245","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42247","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42297","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49863","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49905","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49925","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49930","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49935","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49948","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49949","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49950","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49957","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49962","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50002","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50005","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53131","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57887","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57900","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58095","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21945","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21968","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22022","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22025","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22026","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22039","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22042","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22043","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23133","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37822","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37861","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37899","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37973","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37994","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37997","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38005","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38058","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38071","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38109","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38231","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38282","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38350","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38361","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38443","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38457","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38470","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38477","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38527","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38566","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38588","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38614","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38617","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38636","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38664","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38706","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38727","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39675","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39677","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39684","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39697","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39810","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39817","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39825","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39866","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39881","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39911","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39947","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39994","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39996","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40016","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40049","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40052","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40058","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40061","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40074","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40075","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40104","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40121","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40135","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40139","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40149","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40155","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40158","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2024-38667","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-38667","tags":["report"]},{"url":"https://git.kernel.org/linus/a638b0461b58aa3205cd9d5f14d6f703d795b4af","tags":["report"]},{"url":"https://ubuntu.com/security/notices/USN-6999-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7004-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7005-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7008-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7005-2","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-6999-2","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7029-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7166-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7166-2","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7166-3","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7186-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7186-2","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7194-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7166-4","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2022-48772","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52884","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-23848","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-31076","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-32936","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-33619","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-33621","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-33847","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-34027","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-34030","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-34777","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-35247","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36015","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36244","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36270","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36281","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36286","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36288","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36477","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36478","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36479","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36481","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36484","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36489","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36971","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36972","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36973","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36974","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36978","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-37021","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-37026","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-37078","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-37354","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-37356","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38306","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38381","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38384","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38385","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38388","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38390","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38618","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38619","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38621","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38622","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38623","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38624","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38625","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38627","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38628","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38629","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38630","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38632","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38633","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38634","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38635","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38636","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38637","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38659","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38661","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38662","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38663","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38664","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38780","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39276","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39277","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39291","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39296","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39298","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39301","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39371","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39461","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39462","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39463","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39464","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39465","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39466","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39467","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39468","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39469","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39470","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39471","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39473","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39474","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39475","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39478","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39479","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39480","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39481","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39483","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39485","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39488","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39489","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39490","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39491","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39492","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39493","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39494","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39495","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39496","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39497","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39498","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39499","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39500","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39501","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39502","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39503","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39504","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39505","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39506","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39507","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39508","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39509","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39510","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40899","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40900","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40901","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40902","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40903","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40904","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40905","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40906","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40908","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40909","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40910","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40911","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40912","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40913","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40914","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40915","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40916","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40917","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40918","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40919","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40920","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40921","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40922","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40923","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40924","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40925","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40926","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40927","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40928","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40929","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40930","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40931","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40932","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40933","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40934","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40935","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40936","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40937","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40938","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40939","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40940","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40941","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40942","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40943","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40944","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40945","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40947","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40948","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40949","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40951","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40952","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40953","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40954","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40955","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40956","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40957","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40958","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40959","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40960","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40961","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40962","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40963","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40964","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40965","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40966","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40967","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40968","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40969","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40970","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40971","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40972","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40973","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40974","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40975","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40976","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40977","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40978","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40979","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40980","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40981","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40982","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40983","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40984","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40985","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40986","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40987","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40988","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40989","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40990","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40992","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40994","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40995","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40996","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40997","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40998","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-40999","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41000","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41001","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41002","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41003","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41004","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41005","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41006","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41040","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42078","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42148","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42270","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39292","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39484","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-2023-52532","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52621","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52639","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52904","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52917","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-26947","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-27072","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-35904","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-35951","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36893","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-36968","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38538","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38544","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38545","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41016","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42079","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42156","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42158","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44931","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44940","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44942","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46695","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46849","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-46858","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46859","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46865","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47670","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47671","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47672","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47673","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47674","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47679","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47684","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47685","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47690","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47692","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47693","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47695","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47696","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47697","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47698","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47699","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47701","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47705","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47706","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47709","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47710","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47712","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47713","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47718","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47720","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47723","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47734","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47735","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47737","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47739","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47740","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47742","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47747","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47748","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47749","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47756","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47757","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49851","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49852","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49856","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49858","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49860","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49863","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49866","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49867","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49868","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49871","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49875","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49877","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49878","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49879","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49881","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49882","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49883","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49884","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49886","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49889","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49890","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49892","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49894","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49895","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49896","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49900","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49902","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49903","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49907","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49913","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49924","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49927","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49930","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49933","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49935","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49936","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49938","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49944","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49946","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49948","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49949","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49952","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49954","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49955","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49957","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49958","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49959","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49962","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49963","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49965","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49966","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49967","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49969","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49973","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49975","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49977","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49981","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49982","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49983","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49985","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49995","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-49997","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50000","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50001","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50002","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50003","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50006","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50007","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50008","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50013","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50015","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50019","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50024","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50031","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50033","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50035","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50038","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50039","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50040","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50041","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50044","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50045","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50046","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50049","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50059","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50062","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50093","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50095","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50096","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50179","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50180","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50181","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50184","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50186","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50188","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50189","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50191","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2020-12351","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2020-12352","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2020-24490","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-26822","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-35963","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-35965","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-35966","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-35967","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38553","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43904","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-50264","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-53057","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2022-48666","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-6610","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52434","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52572","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52751","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2023-52757","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-25744","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-26607","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-26661","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-26669","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-26800","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-26893","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38577","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38602","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-38611","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-39472","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41011","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-41019","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41020","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41022","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41042","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-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-41068","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-41077","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41078","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-41081","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-41098","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42114","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42126","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42246","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42259","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-42269","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42271","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-42272","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-42280","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-42292","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-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-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-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-42318","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43817","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-43834","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43835","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43839","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43841","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43846","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43849","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-43858","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-43867","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-43879","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43880","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-43889","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43890","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-43902","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-43905","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-43914","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-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-44954","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44958","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44960","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-44969","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44971","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-44974","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-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-44995","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-45003","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-45011","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45018","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-45021","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-45028","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-46679","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46685","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46689","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46702","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46707","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-46719","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-46731","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46732","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-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-46750","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46752","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-46761","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46763","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46771","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46777","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-46791","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46795","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-46804","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46805","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46807","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46810","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-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-46822","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-46832","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46840","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-46844","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-47663","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2024-47665","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"]}],"sources":{"cve":[{"id":"CVE-2024-38667","title":"riscv: prevent pt_regs corruption for secondary idle threads","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: prevent pt_regs corruption for secondary idle threads\n\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\n\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\"riscv: prevent stack corruption by reserving task_pt_regs(p) early\").\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.","status":"published","published":"2024-06-24T13:52:25.399Z","modified":"2026-05-11T20:20:45.193Z","updated_at":"2026-11-02T14:34:16.367792Z"}],"euvd":[{"id":"EUVD-2024-37519","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: prevent pt_regs corruption for secondary idle threads\n\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\n\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\"riscv: prevent stack corruption by reserving task_pt_regs(p) early\").\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.","status":"published","published":"2024-06-24T13:52:25Z","modified":"2026-05-11T20:20:45Z","updated_at":"2026-11-02T19:04:56.237997Z"}],"ghsa":[{"id":"GHSA-cqg5-mcpx-q78p","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: prevent pt_regs...","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: prevent pt_regs corruption for secondary idle threads\n\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\n\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\"riscv: prevent stack corruption by reserving task_pt_regs(p) early\").\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.","status":"published","published":"2024-06-24T15:31:45Z","modified":"2024-06-26T15:32:03Z","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"}],"cwes":["CWE-787"],"updated_at":"2026-11-02T14:57:32.114808Z"}],"nvd":[{"id":"CVE-2024-38667","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: prevent pt_regs corruption for secondary idle threads\n\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\n\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\"riscv: prevent stack corruption by reserving task_pt_regs(p) early\").\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.","status":"published","published":"2024-06-24T14:15:12.79Z","modified":"2026-06-17T07:40:50.153Z","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":"primary"}],"cwes":["CWE-787"],"updated_at":"2026-11-02T14:10:07.173605Z"}],"osv":[{"id":"AZL-42901","title":"CVE-2024-38667 affecting package kernel for versions less than 6.6.35.1-4","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: prevent pt_regs corruption for secondary idle threads\n\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\n\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\"riscv: prevent stack corruption by reserving task_pt_regs(p) early\").\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.","status":"published","published":"2024-06-24T14:15:12Z","modified":"2026-04-21T04:48:02.460406Z","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:28:04.893995Z"},{"id":"BELL-CVE-2024-38667","status":"published","published":"2024-06-26T05:57:20.998231Z","modified":"2026-01-26T09:36:41.145118Z","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:28:20.200735Z"},{"id":"DEBIAN-CVE-2024-38667","description":"In the Linux kernel, the following vulnerability has been resolved:  riscv: prevent pt_regs corruption for secondary idle threads  Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted.  Similar issue has been fixed for the primary hart, see c7cdd96eca28 (\"riscv: prevent stack corruption by reserving task_pt_regs(p) early\"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context.","status":"published","published":"2024-06-24T14:15:12.79Z","modified":"2026-11-02T12:02:36.772472979Z","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:45:42.835825Z"},{"id":"OESA-2024-2321","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\niommu/vt-d: Fix double list_add when enabling VMD in scalable mode\r\n\r\nWhen enabling VMD and IOMMU scalable mode, the following kernel panic\ncall trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids\nCPU) during booting:\r\n\r\npci 0000:59:00.5: Adding to iommu group 42\n...\nvmd 0000:59:00.5: PCI host bridge to bus 10000:80\npci 10000:80:01.0: [8086:352a] type 01 class 0x060400\npci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:01.0: enabling Extended Tags\npci 10000:80:01.0: PME# supported from D0 D3hot D3cold\npci 10000:80:01.0: DMAR: Setup RID2PASID failed\npci 10000:80:01.0: Failed to add to iommu group 42: -16\npci 10000:80:03.0: [8086:352b] type 01 class 0x060400\npci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:03.0: enabling Extended Tags\npci 10000:80:03.0: PME# supported from D0 D3hot D3cold\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:29!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7\nHardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022\nWorkqueue: events work_for_cpu_fn\nRIP: 0010:__list_add_valid.cold+0x26/0x3f\nCode: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f\n      0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1\n      fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9\n      9e e8 8b b1 fe\nRSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8\nRDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20\nRBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888\nR10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0\nR13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70\nFS:  0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n intel_pasid_alloc_table+0x9c/0x1d0\n dmar_insert_one_dev_info+0x423/0x540\n ? device_to_iommu+0x12d/0x2f0\n intel_iommu_attach_device+0x116/0x290\n __iommu_attach_device+0x1a/0x90\n iommu_group_add_device+0x190/0x2c0\n __iommu_probe_device+0x13e/0x250\n iommu_probe_device+0x24/0x150\n iommu_bus_notifier+0x69/0x90\n blocking_notifier_call_chain+0x5a/0x80\n device_add+0x3db/0x7b0\n ? arch_memremap_can_ram_remap+0x19/0x50\n ? memremap+0x75/0x140\n pci_device_add+0x193/0x1d0\n pci_scan_single_device+0xb9/0xf0\n pci_scan_slot+0x4c/0x110\n pci_scan_child_bus_extend+0x3a/0x290\n vmd_enable_domain.constprop.0+0x63e/0x820\n vmd_probe+0x163/0x190\n local_pci_probe+0x42/0x80\n work_for_cpu_fn+0x13/0x20\n process_one_work+0x1e2/0x3b0\n worker_thread+0x1c4/0x3a0\n ? rescuer_thread+0x370/0x370\n kthread+0xc7/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---\n...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\r\n\r\nThe following \u0026apos;lspci\u0026apos; output shows devices \u0026apos;10000:80:*\u0026apos; are subdevices of\nthe VMD device 0000:59:00.5:\r\n\r\n  $ lspci\n  ...\n  0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)\n  ...\n  10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)\n  10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)\n  10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)\n  10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)\n  10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]\n  10000:82:00\n---truncated---(CVE-2022-48916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  PCI: mt7621: Add sentinel to quirks table  Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call.  This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in:  commit 7c18b64bba3b (\u0026quot;mips: ralink: mt7621: do not use kzalloc too early\u0026quot;)  Fix it by adding the required sentinel.(CVE-2022-48952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()  The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: pci: cx23885: check cx23885_vdev_init() return  cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check.  Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: prevent NULL pointer dereference in vsnprintf()\r\n\r\nIn of_modalias(), we can get passed the str and len parameters which would\ncause a kernel oops in vsnprintf() since it only allows passing a NULL ptr\nwhen the length is also 0. Also, we need to filter out the negative values\nof the len parameter as these will result in a really huge buffer since\nsnprintf() takes size_t parameter while ours is ssize_t...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the Svace static\nanalysis tool.(CVE-2024-35878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: xilinx_dpdma: Fix locking\r\n\r\nThere are several places where either chan-\u0026gt;lock or chan-\u0026gt;vchan.lock was\nnot held. Add appropriate locking. This fixes lockdep warnings like\r\n\r\n[   31.077578] ------------[ cut here ]------------\n[   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.077953] Modules linked in:\n[   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98\n[   31.078102] Hardware name: xlnx,zynqmp (DT)\n[   31.078169] Workqueue: events_unbound deferred_probe_work_func\n[   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0\n[   31.078550] sp : ffffffc083bb2e10\n[   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168\n[   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480\n[   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000\n[   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000\n[   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001\n[   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def\n[   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516\n[   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff\n[   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000\n[   31.080307] Call trace:\n[   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120\n[   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac\n[   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c\n[   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684\n[   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0\n[   31.081139]  commit_tail+0x234/0x294\n[   31.081246]  drm_atomic_helper_commit+0x1f8/0x210\n[   31.081363]  drm_atomic_commit+0x100/0x140\n[   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384\n[   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c\n[   31.081725]  drm_client_modeset_commit+0x34/0x5c\n[   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168\n[   31.081899]  drm_fb_helper_set_par+0x50/0x70\n[   31.081971]  fbcon_init+0x538/0xc48\n[   31.082047]  visual_init+0x16c/0x23c\n[   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634\n[   31.082320]  do_take_over_console+0x24c/0x33c\n[   31.082429]  do_fbcon_takeover+0xbc/0x1b0\n[   31.082503]  fbcon_fb_registered+0x2d0/0x34c\n[   31.082663]  register_framebuffer+0x27c/0x38c\n[   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c\n[   31.082939]  drm_fb_helper_initial_config+0x50/0x74\n[   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108\n[   31.083115]  drm_client_register+0xa0/0xf4\n[   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc\n[   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0\n[   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0\n[   31.083616]  platform_probe+0x8c/0x13c\n[   31.083713]  really_probe+0x258/0x59c\n[   31.083793]  __driver_probe_device+0xc4/0x224\n[   31.083878]  driver_probe_device+0x70/0x1c0\n[   31.083961]  __device_attach_driver+0x108/0x1e0\n[   31.084052]  bus_for_each_drv+0x9c/0x100\n[   31.084125]  __device_attach+0x100/0x298\n[   31.084207]  device_initial_probe+0x14/0x20\n[   31.084292]  bus_probe_device+0xd8/0xdc\n[   31.084368]  deferred_probe_work_func+0x11c/0x180\n[   31.084451]  process_one_work+0x3ac/0x988\n[   31.084643]  worker_thread+0x398/0x694\n[   31.084752]  kthread+0x1bc/0x1c0\n[   31.084848]  ret_from_fork+0x10/0x20\n[   31.084932] irq event stamp: 64549\n[   31.084970] hardirqs last  enabled at (64548): [\u0026lt;ffffffc081adf35c\u0026gt;] _raw_spin_unlock_irqrestore+0x80/0x90\n[   31.085157]\n---truncated---(CVE-2024-35990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\r\n\r\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\r\n\r\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\r\n\r\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\r\n\r\nother info that might help us debug this:\r\n\r\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\r\n\r\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\n  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\n  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\n  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\n  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\n  rcu_do_batch kernel/rcu/tree.c:2196 [inline]\n  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\n  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n  __do_softirq kernel/softirq.c:588 [inline]\n  invoke_softirq kernel/softirq.c:428 [inline]\n  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\n  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649\n  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\n  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;(CVE-2024-36286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: core: Fix NULL module pointer assignment at card init\r\n\r\nThe commit 81033c6b584b (\u0026quot;ALSA: core: Warn on empty module\u0026quot;)\nintroduced a WARN_ON() for a NULL module pointer passed at snd_card\nobject creation, and it also wraps the code around it with \u0026apos;#ifdef\nMODULE\u0026apos;.  This works in most cases, but the devils are always in\ndetails.  \u0026quot;MODULE\u0026quot; is defined when the target code (i.e. the sound\ncore) is built as a module; but this doesn\u0026apos;t mean that the caller is\nalso built-in or not.  Namely, when only the sound core is built-in\n(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),\nthe passed module pointer is ignored even if it\u0026apos;s non-NULL, and\ncard-\u0026gt;module remains as NULL.  This would result in the missing module\nreference up/down at the device open/close, leading to a race with the\ncode execution after the module removal.\r\n\r\nFor addressing the bug, move the assignment of card-\u0026gt;module again out\nof ifdef.  The WARN_ON() is still wrapped with ifdef because the\nmodule can be really NULL when all sound drivers are built-in.\r\n\r\nNote that we keep \u0026apos;ifdef MODULE\u0026apos; for WARN_ON(), otherwise it would\nlead to a false-positive NULL module check.  Admittedly it won\u0026apos;t catch\nperfectly, i.e. no check is performed when CONFIG_SND=y.  But, it\u0026apos;s no\nreal problem as it\u0026apos;s only for debugging, and the condition is pretty\nrare.(CVE-2024-38605)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoundwire: cadence: fix invalid PDI offset\r\n\r\nFor some reason, we add an offset to the PDI, presumably to skip the\nPDI0 and PDI1 which are reserved for BPT.\r\n\r\nThis code is however completely wrong and leads to an out-of-bounds\naccess. We were just lucky so far since we used only a couple of PDIs\nand remained within the PDI array bounds.\r\n\r\nA Fixes: tag is not provided since there are no known platforms where\nthe out-of-bounds would be accessed, and the initial code had problems\nas well.\r\n\r\nA follow-up patch completely removes this useless offset.(CVE-2024-38635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: prevent pt_regs corruption for secondary idle threads\r\n\r\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\r\n\r\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\u0026quot;riscv: prevent stack corruption by reserving task_pt_regs(p) early\u0026quot;).\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.(CVE-2024-38667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\r\n\r\nIn nvmet_sq_destroy we capture sq-\u0026gt;ctrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u0026gt;sqs and sq-\u0026gt;ctrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\r\n\r\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u0026gt;ref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u0026gt;ctrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\r\n\r\nSolve this by re-capturing the sq-\u0026gt;ctrl after all inflight request has\ncompleted, where for sure sq-\u0026gt;ctrl reference is final, and move forward\nbased on that.\r\n\r\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.(CVE-2024-42152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexfat: fix potential deadlock on __exfat_get_dentry_set\r\n\r\nWhen accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array\nis allocated in __exfat_get_entry_set. The problem is that the bh-array is\nallocated with GFP_KERNEL. It does not make sense. In the following cases,\na deadlock for sbi-\u0026gt;s_lock between the two processes may occur.\r\n\r\n       CPU0                CPU1\n       ----                ----\n  kswapd\n   balance_pgdat\n    lock(fs_reclaim)\n                      exfat_iterate\n                       lock(\u0026amp;sbi-\u0026gt;s_lock)\n                       exfat_readdir\n                        exfat_get_uniname_from_ext_entry\n                         exfat_get_dentry_set\n                          __exfat_get_dentry_set\n                           kmalloc_array\n                            ...\n                            lock(fs_reclaim)\n    ...\n    evict\n     exfat_evict_inode\n      lock(\u0026amp;sbi-\u0026gt;s_lock)\r\n\r\nTo fix this, let\u0026apos;s allocate bh-array with GFP_NOFS.(CVE-2024-42315)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: virt_wifi: avoid reporting connection success with wrong SSID\r\n\r\nWhen user issues a connection with a different SSID than the one\nvirt_wifi has advertised, the __cfg80211_connect_result() will\ntrigger the warning: WARN_ON(bss_not_found).\r\n\r\nThe issue is because the connection code in virt_wifi does not\ncheck the SSID from user space (it only checks the BSSID), and\nvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS\neven if the SSID is different from the one virt_wifi has advertised.\nEventually cfg80211 won\u0026apos;t be able to find the cfg80211_bss and generate\nthe warning.\r\n\r\nFixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: prime: fix refcount underflow\r\n\r\nCalling nouveau_bo_ref() on a nouveau_bo without initializing it (and\nhence the backing ttm_bo) leads to a refcount underflow.\r\n\r\nInstead of calling nouveau_bo_ref() in the unwind path of\ndrm_gem_object_init(), clean things up manually.\r\n\r\n(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\r\n\r\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u0026gt;mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)\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\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n        1. In dwc3_gadget_suspend, there is a chance of a timeout when\n        moving the USB core to the halt state after clearing the\n        run/stop bit by software.\n        2. In dwc3_core_exit, the event buffer is cleared regardless of\n        the USB core\u0026apos;s status, which may lead to an SMMU faults and\n        other memory issues. if the USB core tries to access the event\n        buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software  when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\r\n\r\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \u0026quot;write\u0026quot; into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\r\n\r\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\r\n\r\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\r\n\r\nI tested this on SA8155P with Xen.(CVE-2024-46689)\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 read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (nct6775-core) 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-46757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: added NULL check at start of dc_validate_stream\r\n\r\n[Why]\nprevent invalid memory access\r\n\r\n[How]\ncheck if dc and stream are NULL(CVE-2024-46802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86: Acquire kvm-\u0026gt;srcu when handling KVM_SET_VCPU_EVENTS\r\n\r\nGrab kvm-\u0026gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly\nleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX\nreads guest memory.\r\n\r\nNote, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN\nvia sync_regs(), which already holds SRCU.  I.e. trying to precisely use\nkvm_vcpu_srcu_read_lock() around the problematic SMM code would cause\nproblems.  Acquiring SRCU isn\u0026apos;t all that expensive, so for simplicity,\ngrab it unconditionally for KVM_SET_VCPU_EVENTS.\r\n\r\n =============================\n WARNING: suspicious RCU usage\n 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!\r\n\r\n other info that might help us debug this:\r\n\r\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by repro/1071:\n  #0: ffff88811e424430 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]\r\n\r\n stack backtrace:\n CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  dump_stack_lvl+0x7f/0x90\n  lockdep_rcu_suspicious+0x13f/0x1a0\n  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]\n  kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]\n  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]\n  vmx_leave_nested+0x30/0x40 [kvm_intel]\n  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]\n  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]\n  ? mark_held_locks+0x49/0x70\n  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]\n  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  ? lock_acquire+0xba/0x2d0\n  ? find_held_lock+0x2b/0x80\n  ? do_user_addr_fault+0x40c/0x6f0\n  ? lock_release+0xb7/0x270\n  __x64_sys_ioctl+0x82/0xb0\n  do_syscall_64+0x6c/0x170\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7ff11eb1b539\n  \u0026lt;/TASK\u0026gt;(CVE-2024-46830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: nxp-fspi: fix the KASAN report out-of-bounds bug\r\n\r\nChange the memcpy length to fix the out-of-bounds issue when writing the\ndata that is not 4 byte aligned to TX FIFO.\r\n\r\nTo reproduce the issue, write 3 bytes data to NOR chip.\r\n\r\ndd if=3b of=/dev/mtd0\n[   36.926103] ==================================================================\n[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838\n[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455\n[   36.946721]\n[   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070\n[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)\n[   36.961260] Call trace:\n[   36.963723]  dump_backtrace+0x90/0xe8\n[   36.967414]  show_stack+0x18/0x24\n[   36.970749]  dump_stack_lvl+0x78/0x90\n[   36.974451]  print_report+0x114/0x5cc\n[   36.978151]  kasan_report+0xa4/0xf0\n[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28\n[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838\n[   36.990800]  spi_mem_exec_op+0x8ec/0xd30\n[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0\n[   36.999323]  spi_mem_dirmap_write+0x238/0x32c\n[   37.003710]  spi_nor_write_data+0x220/0x374\n[   37.007932]  spi_nor_write+0x110/0x2e8\n[   37.011711]  mtd_write_oob_std+0x154/0x1f0\n[   37.015838]  mtd_write_oob+0x104/0x1d0\n[   37.019617]  mtd_write+0xb8/0x12c\n[   37.022953]  mtdchar_write+0x224/0x47c\n[   37.026732]  vfs_write+0x1e4/0x8c8\n[   37.030163]  ksys_write+0xec/0x1d0\n[   37.033586]  __arm64_sys_write+0x6c/0x9c\n[   37.037539]  invoke_syscall+0x6c/0x258\n[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.046244]  do_el0_svc+0x44/0x5c\n[   37.049589]  el0_svc+0x38/0x78\n[   37.052681]  el0t_64_sync_handler+0x13c/0x158\n[   37.057077]  el0t_64_sync+0x190/0x194\n[   37.060775]\n[   37.062274] Allocated by task 455:\n[   37.065701]  kasan_save_stack+0x2c/0x54\n[   37.069570]  kasan_save_track+0x20/0x3c\n[   37.073438]  kasan_save_alloc_info+0x40/0x54\n[   37.077736]  __kasan_kmalloc+0xa0/0xb8\n[   37.081515]  __kmalloc_noprof+0x158/0x2f8\n[   37.085563]  mtd_kmalloc_up_to+0x120/0x154\n[   37.089690]  mtdchar_write+0x130/0x47c\n[   37.093469]  vfs_write+0x1e4/0x8c8\n[   37.096901]  ksys_write+0xec/0x1d0\n[   37.100332]  __arm64_sys_write+0x6c/0x9c\n[   37.104287]  invoke_syscall+0x6c/0x258\n[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.112972]  do_el0_svc+0x44/0x5c\n[   37.116319]  el0_svc+0x38/0x78\n[   37.119401]  el0t_64_sync_handler+0x13c/0x158\n[   37.123788]  el0t_64_sync+0x190/0x194\n[   37.127474]\n[   37.128977] The buggy address belongs to the object at ffff00081037c2a0\n[   37.128977]  which belongs to the cache kmalloc-8 of size 8\n[   37.141177] The buggy address is located 0 bytes inside of\n[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)\n[   37.153465]\n[   37.154971] The buggy address belongs to the physical page:\n[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c\n[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)\n[   37.175149] page_type: 0xfdffffff(slab)\n[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000\n[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000\n[   37.194553] page dumped because: kasan: bad access detected\n[   37.200144]\n[   37.201647] Memory state around the buggy address:\n[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc\n[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc\n[   37.220946] \u0026gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc\n[   37.228186]                                ^\n[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.246962] ==============================================================\n---truncated---(CVE-2024-46853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)\r\n\r\nErrata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0\n(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an\ninbound PCIe TLP spans more than two internal AXI 128-byte bursts,\nthe bus may corrupt the packet payload and the corrupt data may\ncause associated applications or the processor to hang.\r\n\r\nThe workaround for Errata #i2037 is to limit the maximum read\nrequest size and maximum payload size to 128 bytes. Add workaround\nfor Errata #i2037 here.\r\n\r\nThe errata and workaround is applicable only to AM65x SR 1.0 and\nlater versions of the silicon will have this fixed.\r\n\r\n[1] -\u0026gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared.  This causes page cache operations to\nhang waiting for the writeback flag.  For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp: check skb is non-NULL in tcp_rto_delta_us()  We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases:  Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u0026lt;48\u0026gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()  syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1)  Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put()  BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core net/core/dev.c:5661 [inline]   __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775   process_backlog+0x4ad/0xa50 net/core/dev.c:6108   __napi_poll+0xe7/0x980 net/core/dev.c:6772   napi_poll net/core/dev.c:6841 [inline]   net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963   handle_softirqs+0x1ce/0x800 kernel/softirq.c:554   __do_softirq+0x14/0x1a kernel/softirq.c:588   do_softirq+0x9a/0x100 kernel/softirq.c:455   __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382   local_bh_enable include/linux/bottom_half.h:33 [inline]   rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]   __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450   dev_queue_xmit include/linux/netdevice.h:3105 [inline]   neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565   neigh_output include/net/neighbour.h:542 [inline]   ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141   __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]   ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226   NF_HOOK_COND include/linux/netfilter.h:303 [inline]   ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247   dst_output include/net/dst.h:450 [inline]   NF_HOOK include/linux/netfilter.h:314 [inline]   ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366   inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135   __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]   tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143   tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333   __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679   inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750   __sys_connect_file net/socket.c:2061 [inline]   __sys_connect+0x606/0x690 net/socket.c:2078   __do_sys_connect net/socket.c:2088 [inline]   __se_sys_connect net/socket.c:2085 [inline]   __x64_sys_connect+0x91/0xe0 net/socket.c:2085   x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was stored to memory at:   nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: return -EINVAL when namelen is 0  When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered.  [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]  dump_stack+0x9a/0xd0 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  __kasan_report.cold+0x34/0x84 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  kasan_report+0x3a/0x50 [ T1205]  nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  ? nfsd4_release_lockowner+0x410/0x410 [ T1205]  cld_pipe_downcall+0x5ca/0x760 [ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]  ? down_write_killable_nested+0x170/0x170 [ T1205]  ? avc_policy_seqno+0x28/0x40 [ T1205]  ? selinux_file_permission+0x1b4/0x1e0 [ T1205]  rpc_pipe_write+0x84/0xb0 [ T1205]  vfs_write+0x143/0x520 [ T1205]  ksys_write+0xc9/0x170 [ T1205]  ? __ia32_sys_read+0x50/0x50 [ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]  do_syscall_64+0x33/0x40 [ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ==================================================================  Fix it by checking namelen.(CVE-2024-47692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds  In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-\u0026gt;s.con_num.  This commits resets the cid to clt_path-\u0026gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error  Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access.  dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue.  [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry().  syzbot reported a warning in bcm_release(). [0]  The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered.  However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release().  Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify().  [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  bcm_release+0x250/0x880 net/can/bcm.c:1578  __sock_release net/socket.c:659 [inline]  sock_close+0xbc/0x240 net/socket.c:1421  __fput+0x24a/0x8a0 fs/file_table.c:422  task_work_run+0x24f/0x310 kernel/task_work.c:228  exit_task_work include/linux/task_work.h:40 [inline]  do_exit+0xa2f/0x27f0 kernel/exit.c:882  do_group_exit+0x207/0x2c0 kernel/exit.c:1031  __do_sys_exit_group kernel/exit.c:1042 [inline]  __se_sys_exit_group kernel/exit.c:1040 [inline]  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160  \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  sock_map: Add a cond_resched() in sock_hash_free()  Several syzbot soft lockup reports all have in common sock_hash_free()  If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the  dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function.  This fix prevents a potential null pointer dereference error.  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed \u0026apos;mpc-\u0026gt;funcs-\u0026gt;set_output_gamma\u0026apos; could be null (see line 386)  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c     373 bool dcn30_set_output_transfer_func(struct dc *dc,     374                                 struct pipe_ctx *pipe_ctx,     375                                 const struct dc_stream_state *stream)     376 {     377         int mpcc_id = pipe_ctx-\u0026gt;plane_res.hubp-\u0026gt;inst;     378         struct mpc *mpc = pipe_ctx-\u0026gt;stream_res.opp-\u0026gt;ctx-\u0026gt;dc-\u0026gt;res_pool-\u0026gt;mpc;     379         const struct pwl_params *params = NULL;     380         bool ret = false;     381     382         /* program OGAM or 3DLUT only for the top pipe*/     383         if (pipe_ctx-\u0026gt;top_pipe == NULL) {     384                 /*program rmu shaper and 3dlut in MPC*/     385                 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);     386                 if (ret == false \u0026amp;\u0026amp; mpc-\u0026gt;funcs-\u0026gt;set_output_gamma) {                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL      387                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_HWPWL)     388                                 params = \u0026amp;stream-\u0026gt;out_transfer_func.pwl;     389                         else if (pipe_ctx-\u0026gt;stream-\u0026gt;out_transfer_func.type ==     390                                         TF_TYPE_DISTRIBUTED_POINTS \u0026amp;\u0026amp;     391                                         cm3_helper_translate_curve_to_hw_format(     392                                         \u0026amp;stream-\u0026gt;out_transfer_func,     393                                         \u0026amp;mpc-\u0026gt;blender_params, false))     394                                 params = \u0026amp;mpc-\u0026gt;blender_params;     395                          /* there are no ROM LUTs in OUTGAM */     396                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_PREDEFINED)     397                                 BREAK_TO_DEBUGGER();     398                 }     399         }     400 --\u0026gt; 401         mpc-\u0026gt;funcs-\u0026gt;set_output_gamma(mpc, mpcc_id, params);                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash      402         return ret;     403 }(CVE-2024-47720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled  Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold.  This was discovered through the lock debugging, and the corresponding log is as follows:  raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace:  warn_bogus_irq_restore+0x30/0x40  _raw_spin_unlock_irqrestore+0x84/0xc8  add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]  hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]  hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]  create_qp+0x138/0x258  ib_create_qp_kernel+0x50/0xe8  create_mad_qp+0xa8/0x128  ib_mad_port_open+0x218/0x448  ib_mad_init_device+0x70/0x1f8  add_client_context+0xfc/0x220  enable_device_and_get+0xd0/0x140  ib_register_device.part.0+0xf4/0x1c8  ib_register_device+0x34/0x50  hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]  hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]  __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]  hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: call cache_put if xdr_reserve_space returns NULL  If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get.  Reviwed-by: Jeff Layton \u0026lt;jlayton@kernel.org\u0026gt;(CVE-2024-47737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential oob read in nilfs_btree_check_delete()  The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries.  This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing/timerlat: Fix a race during cpuhp processing  There is another found exception that the \u0026quot;timerlat/1\u0026quot; thread was scheduled on CPU0, and lead to timer corruption finally:  ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace:  \u0026lt;TASK\u0026gt;  ? __warn+0x7c/0x110  ? debug_print_object+0x7d/0xb0  ? report_bug+0xf1/0x1d0  ? prb_read_valid+0x17/0x20  ? handle_bug+0x3f/0x70  ? exc_invalid_op+0x13/0x60  ? asm_exc_invalid_op+0x16/0x20  ? debug_print_object+0x7d/0xb0  ? debug_print_object+0x7d/0xb0  ? __pfx_timerlat_irq+0x10/0x10  __debug_object_init+0x110/0x150  hrtimer_init+0x1d/0x60  timerlat_main+0xab/0x2d0  ? __pfx_timerlat_main+0x10/0x10  kthread+0xb7/0xe0  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2d/0x40  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  \u0026lt;/TASK\u0026gt; ```  After tracing the scheduling event, it was discovered that the migration of the \u0026quot;timerlat/1\u0026quot; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU:  T1                       | T2 [CPUHP_ONLINE]           | cpu_device_down() osnoise_hotplug_workfn() |                          |     cpus_write_lock()                          |     takedown_cpu(1)                          |     cpus_write_unlock() [CPUHP_OFFLINE]          |     cpus_read_lock()     |     start_kthread(1)     |     cpus_read_unlock()   |  To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: wait for fixup workers before stopping cleaner kthread during umount  During unmount, at close_ctree(), we have the following steps in this order:  1) Park the cleaner kthread - this doesn\u0026apos;t destroy the kthread, it basically    halts its execution (wake ups against it work but do nothing);  2) We stop the cleaner kthread - this results in freeing the respective    struct task_struct;  3) We call btrfs_stop_all_workers() which waits for any jobs running in all    the work queues and then free the work queues.  Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don\u0026apos;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources.  Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs.  The stack traces reported by syzbot were the following:    BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065   Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52    CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024   Workqueue: btrfs-fixup btrfs_work_helper   Call Trace:    \u0026lt;TASK\u0026gt;    __dump_stack lib/dump_stack.c:94 [inline]    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120    print_address_description mm/kasan/report.c:377 [inline]    print_report+0x169/0x550 mm/kasan/report.c:488    kasan_report+0x143/0x180 mm/kasan/report.c:601    __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065    lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825    __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]    _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162    class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]    try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154    btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842    btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314    process_one_work kernel/workqueue.c:3229 [inline]    process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310    worker_thread+0x870/0xd30 kernel/workqueue.c:3391    kthread+0x2f0/0x390 kernel/kthread.c:389    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    \u0026lt;/TASK\u0026gt;    Allocated by task 2:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    unpoison_slab_object mm/kasan/common.c:319 [inline]    __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345    kasan_slab_alloc include/linux/kasan.h:247 [inline]    slab_post_alloc_hook mm/slub.c:4086 [inline]    slab_alloc_node mm/slub.c:4135 [inline]    kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187    alloc_task_struct_node kernel/fork.c:180 [inline]    dup_task_struct+0x57/0x8c0 kernel/fork.c:1107    copy_process+0x5d1/0x3d50 kernel/fork.c:2206    kernel_clone+0x223/0x880 kernel/fork.c:2787    kernel_thread+0x1bc/0x240 kernel/fork.c:2849    create_kthread kernel/kthread.c:412 [inline]    kthreadd+0x60d/0x810 kernel/kthread.c:765    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    Freed by task 61:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579    poison_slab_object mm/kasan/common.c:247 [inline]    __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264    kasan_slab_free include/linux/kasan.h:230 [inline]    slab_free_h ---truncated---(CVE-2024-49867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix a NULL pointer dereference when failed to start a new trasacntion  [BUG] Syzbot reported a NULL pointer dereference with the following crash:    FAULT_INJECTION: forcing a failure.    start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676    prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642    relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678   ...   BTRFS info (device loop0): balance: ended with status: -12   Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI   KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]   RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926   Call Trace:    \u0026lt;TASK\u0026gt;    commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496    btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430    del_balance_item fs/btrfs/volumes.c:3678 [inline]    reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742    btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574    btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673    vfs_ioctl fs/ioctl.c:51 [inline]    __do_sys_ioctl fs/ioctl.c:907 [inline]    __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893    do_syscall_x64 arch/x86/entry/common.c:52 [inline]    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83    entry_SYSCALL_64_after_hwframe+0x77/0x7f  [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-\u0026gt;balance_ctl to be NULL.  Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree.  However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume.  Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots().  That function checks if fs_info-\u0026gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-\u0026gt;reloc_ctl is NULL, it results a NULL pointer dereference.  [FIX] Just add extra check on fs_info-\u0026gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-\u0026gt;reloc_ctl-\u0026gt;merge_reloc_tree.  That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: map the EBADMSG to nfserr_io to avoid warning  Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING.  Fix it by mapping EBADMSG to nfserr_io.  nfsd_buffered_readdir  iterate_dir // -EBADMSG -74   ext4_readdir // .iterate_shared    ext4_dx_readdir     ext4_htree_fill_tree      htree_dirblock_to_tree       ext4_read_dirblock        __ext4_read_dirblock         ext4_dirblock_csum_verify          warn_no_space_for_csum           __warn_no_space_for_csum         return ERR_PTR(-EFSBADCRC) // -EBADMSG -74  nfserrno // WARNING  [  161.115610] ------------[ cut here ]------------ [  161.116465] nfsd: non-standard errno: -74 [  161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [  161.118596] Modules linked in: [  161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [  161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [  161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [  161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6  05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [  161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [  161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [  161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [  161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [  161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [  161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [  161.135244] FS:  0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [  161.136695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [  161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [  161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [  161.141519] PKRU: 55555554 [  161.142076] Call Trace: [  161.142575]  ? __warn+0x9b/0x140 [  161.143229]  ? nfserrno+0x9d/0xd0 [  161.143872]  ? report_bug+0x125/0x150 [  161.144595]  ? handle_bug+0x41/0x90 [  161.145284]  ? exc_invalid_op+0x14/0x70 [  161.146009]  ? asm_exc_invalid_op+0x12/0x20 [  161.146816]  ? nfserrno+0x9d/0xd0 [  161.147487]  nfsd_buffered_readdir+0x28b/0x2b0 [  161.148333]  ? nfsd4_encode_dirent_fattr+0x380/0x380 [  161.149258]  ? nfsd_buffered_filldir+0xf0/0xf0 [  161.150093]  ? wait_for_concurrent_writes+0x170/0x170 [  161.151004]  ? generic_file_llseek_size+0x48/0x160 [  161.151895]  nfsd_readdir+0x132/0x190 [  161.152606]  ? nfsd4_encode_dirent_fattr+0x380/0x380 [  161.153516]  ? nfsd_unlink+0x380/0x380 [  161.154256]  ? override_creds+0x45/0x60 [  161.155006]  nfsd4_encode_readdir+0x21a/0x3d0 [  161.155850]  ? nfsd4_encode_readlink+0x210/0x210 [  161.156731]  ? write_bytes_to_xdr_buf+0x97/0xe0 [  161.157598]  ? __write_bytes_to_xdr_buf+0xd0/0xd0 [  161.158494]  ? lock_downgrade+0x90/0x90 [  161.159232]  ? nfs4svc_decode_voidarg+0x10/0x10 [  161.160092]  nfsd4_encode_operation+0x15a/0x440 [  161.160959]  nfsd4_proc_compound+0x718/0xe90 [  161.161818]  nfsd_dispatch+0x18e/0x2c0 [  161.162586]  svc_process_common+0x786/0xc50 [  161.163403]  ? nfsd_svc+0x380/0x380 [  161.164137]  ? svc_printk+0x160/0x160 [  161.164846]  ? svc_xprt_do_enqueue.part.0+0x365/0x380 [  161.165808]  ? nfsd_svc+0x380/0x380 [  161.166523]  ? rcu_is_watching+0x23/0x40 [  161.167309]  svc_process+0x1a5/0x200 [  161.168019]  nfsd+0x1f5/0x380 [  161.168663]  ? nfsd_shutdown_threads+0x260/0x260 [  161.169554]  kthread+0x1c4/0x210 [  161.170224]  ? kthread_insert_work_sanity_check+0x80/0x80 [  161.171246]  ret_from_fork+0x1f/0x30(CVE-2024-49875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Initialize get_bytes_per_element\u0026apos;s default to 1  Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y \u0026amp; bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0.  This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in degamma hardware format translation  Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color  management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the  number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uninit-value access of new_ea in ea_buffer  syzbot reports that lzo1x_1_do_compress is using uninit-value:  ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178  ...  Uninit was stored to memory at:  ea_put fs/jfs/xattr.c:639 [inline]  ...  Local variable ea_buf created at:  __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662  __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934  =====================================================  The reason is ea_buf-\u0026gt;new_ea is not initialized properly.  Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: check if leafidx greater than num leaves per dmap tree  syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.  Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uaf in dbFreeBits  [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216  CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  __mutex_lock_common kernel/locking/mutex.c:587 [inline]  __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752  dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390  dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]  dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409  dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650  jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100  jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  Freed by task 5218:  kasan_save_stack mm/kasan/common.c:47 [inline]  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2252 [inline]  slab_free mm/slub.c:4473 [inline]  kfree+0x149/0x360 mm/slub.c:4594  dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278  jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247  jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454  reconfigure_super+0x445/0x880 fs/super.c:1083  vfs_cmd_reconfigure fs/fsopen.c:263 [inline]  vfs_fsconfig_locked fs/fsopen.c:292 [inline]  __do_sys_fsconfig fs/fsopen.c:473 [inline]  __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf.  Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/ioapic: Handle allocation failures gracefully  Breno observed panics when using failslab under certain conditions during runtime:     can not alloc irq_pin_list (-1,0,20)    Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed     panic+0x4e9/0x590    mp_irqdomain_alloc+0x9ab/0xa80    irq_domain_alloc_irqs_locked+0x25d/0x8d0    __irq_domain_alloc_irqs+0x80/0x110    mp_map_pin_to_irq+0x645/0x890    acpi_register_gsi_ioapic+0xe6/0x150    hpet_open+0x313/0x480  That\u0026apos;s a pointless panic which is a leftover of the historic IO/APIC code which panic\u0026apos;ed during early boot when the interrupt allocation failed.  The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode.  Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error  In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain:  ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace:  \u0026lt;TASK\u0026gt;  add_transaction_credits+0x5d1/0x5e0  start_this_handle+0x1ef/0x6a0  jbd2__journal_start+0x18b/0x340  ext4_dirty_inode+0x5d/0xb0  __mark_inode_dirty+0xe4/0x5d0  generic_update_time+0x60/0x70 [...] ============================================  So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways.  Note that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt when updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove unreasonable unlock in ocfs2_read_blocks  Patch series \u0026quot;Misc fixes for ocfs2_read_blocks\u0026quot;, v5.  This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks().  The second patch fixes an issue reported by Heming Zhao when reviewing above fix.   This patch (of 2):  There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: cancel dqi_sync_work before freeing oinfo  ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:  ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c  This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first.  BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 color transformation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSD: Limit the number of concurrent async COPY operations  Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector.  Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit.  An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy.  If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume  In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.  This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks.  Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: fnic: Move flush_work initialization out of if block  After commit 379a58caa199 (\u0026quot;scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\u0026quot;), it can happen that a work item is sent to an uninitialized work queue.  This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed.  The following warning is observed while the fnic driver is loaded:  kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel:  \u0026lt;IRQ\u0026gt; kernel:  queue_work_on+0x3a/0x50 kernel:  fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  __handle_irq_event_percpu+0x36/0x1a0 kernel:  handle_irq_event_percpu+0x30/0x70 kernel:  handle_irq_event+0x34/0x60 kernel:  handle_edge_irq+0x7e/0x1a0 kernel:  __common_interrupt+0x3b/0xb0 kernel:  common_interrupt+0x58/0xa0 kernel:  \u0026lt;/IRQ\u0026gt;  It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure.  This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: do not delay dst_entries_add() in dst_release()  dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy()  Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy()  dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already.  Decrementing the number of dsts must happen sooner.  Notes:  1) in CONFIG_XFRM case, dst_destroy() can call    dst_release_immediate(child), this might also cause UAF    if the child does not have DST_NOCOUNT set.    IPSEC maintainers might take a look and see how to address this.  2) There is also discussion about removing this count of dst,    which might happen in future kernels.(CVE-2024-50036)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()  On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog:  [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701]   ESR = 0x0000000096000007 [232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084]   SET = 0, FnV = 0 [232066.589216]   EA = 0, S1PTW = 0 [232066.589340]   FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683]   ISV = 0, ISS = 0x00000007 [232066.589842]   CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before dereferencing se  [WHAT \u0026amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)","status":"published","published":"2024-11-01T11:07:47Z","modified":"2026-08-18T01:17:36.529649285Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","level":"critical"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2024-2322","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\niommu/vt-d: Fix double list_add when enabling VMD in scalable mode\r\n\r\nWhen enabling VMD and IOMMU scalable mode, the following kernel panic\ncall trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids\nCPU) during booting:\r\n\r\npci 0000:59:00.5: Adding to iommu group 42\n...\nvmd 0000:59:00.5: PCI host bridge to bus 10000:80\npci 10000:80:01.0: [8086:352a] type 01 class 0x060400\npci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:01.0: enabling Extended Tags\npci 10000:80:01.0: PME# supported from D0 D3hot D3cold\npci 10000:80:01.0: DMAR: Setup RID2PASID failed\npci 10000:80:01.0: Failed to add to iommu group 42: -16\npci 10000:80:03.0: [8086:352b] type 01 class 0x060400\npci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:03.0: enabling Extended Tags\npci 10000:80:03.0: PME# supported from D0 D3hot D3cold\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:29!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7\nHardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022\nWorkqueue: events work_for_cpu_fn\nRIP: 0010:__list_add_valid.cold+0x26/0x3f\nCode: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f\n      0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1\n      fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9\n      9e e8 8b b1 fe\nRSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8\nRDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20\nRBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888\nR10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0\nR13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70\nFS:  0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n intel_pasid_alloc_table+0x9c/0x1d0\n dmar_insert_one_dev_info+0x423/0x540\n ? device_to_iommu+0x12d/0x2f0\n intel_iommu_attach_device+0x116/0x290\n __iommu_attach_device+0x1a/0x90\n iommu_group_add_device+0x190/0x2c0\n __iommu_probe_device+0x13e/0x250\n iommu_probe_device+0x24/0x150\n iommu_bus_notifier+0x69/0x90\n blocking_notifier_call_chain+0x5a/0x80\n device_add+0x3db/0x7b0\n ? arch_memremap_can_ram_remap+0x19/0x50\n ? memremap+0x75/0x140\n pci_device_add+0x193/0x1d0\n pci_scan_single_device+0xb9/0xf0\n pci_scan_slot+0x4c/0x110\n pci_scan_child_bus_extend+0x3a/0x290\n vmd_enable_domain.constprop.0+0x63e/0x820\n vmd_probe+0x163/0x190\n local_pci_probe+0x42/0x80\n work_for_cpu_fn+0x13/0x20\n process_one_work+0x1e2/0x3b0\n worker_thread+0x1c4/0x3a0\n ? rescuer_thread+0x370/0x370\n kthread+0xc7/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---\n...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\r\n\r\nThe following \u0026apos;lspci\u0026apos; output shows devices \u0026apos;10000:80:*\u0026apos; are subdevices of\nthe VMD device 0000:59:00.5:\r\n\r\n  $ lspci\n  ...\n  0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)\n  ...\n  10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)\n  10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)\n  10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)\n  10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)\n  10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]\n  10000:82:00\n---truncated---(CVE-2022-48916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  PCI: mt7621: Add sentinel to quirks table  Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call.  This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in:  commit 7c18b64bba3b (\u0026quot;mips: ralink: mt7621: do not use kzalloc too early\u0026quot;)  Fix it by adding the required sentinel.(CVE-2022-48952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  memcg: fix possible use-after-free in memcg_write_event_control()  memcg_write_event_control() accesses the dentry-\u0026gt;d_name of the specified control fd to route the write call.  As a cgroup interface file can\u0026apos;t be renamed, it\u0026apos;s safe to access d_name as long as the specified file is a regular cgroup file.  Also, as these cgroup interface files can\u0026apos;t be removed before the directory, it\u0026apos;s safe to access the parent too.  Prior to 347c4a874710 (\u0026quot;memcg: remove cgroup_event-\u0026gt;cft\u0026quot;), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses.  The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through.  With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free\u0026apos;s.  Fix the bug by resurrecting the file type check in __file_cft().  Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection.  Instead, let\u0026apos;s check the superblock and dentry type.(CVE-2022-48988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()  The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: pci: cx23885: check cx23885_vdev_init() return  cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check.  Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfc: nci: fix possible NULL pointer dereference in send_acknowledge()  Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: prevent NULL pointer dereference in vsnprintf()\r\n\r\nIn of_modalias(), we can get passed the str and len parameters which would\ncause a kernel oops in vsnprintf() since it only allows passing a NULL ptr\nwhen the length is also 0. Also, we need to filter out the negative values\nof the len parameter as these will result in a really huge buffer since\nsnprintf() takes size_t parameter while ours is ssize_t...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the Svace static\nanalysis tool.(CVE-2024-35878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: xilinx_dpdma: Fix locking\r\n\r\nThere are several places where either chan-\u0026gt;lock or chan-\u0026gt;vchan.lock was\nnot held. Add appropriate locking. This fixes lockdep warnings like\r\n\r\n[   31.077578] ------------[ cut here ]------------\n[   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.077953] Modules linked in:\n[   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98\n[   31.078102] Hardware name: xlnx,zynqmp (DT)\n[   31.078169] Workqueue: events_unbound deferred_probe_work_func\n[   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0\n[   31.078550] sp : ffffffc083bb2e10\n[   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168\n[   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480\n[   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000\n[   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000\n[   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001\n[   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def\n[   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516\n[   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff\n[   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000\n[   31.080307] Call trace:\n[   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120\n[   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac\n[   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c\n[   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684\n[   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0\n[   31.081139]  commit_tail+0x234/0x294\n[   31.081246]  drm_atomic_helper_commit+0x1f8/0x210\n[   31.081363]  drm_atomic_commit+0x100/0x140\n[   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384\n[   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c\n[   31.081725]  drm_client_modeset_commit+0x34/0x5c\n[   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168\n[   31.081899]  drm_fb_helper_set_par+0x50/0x70\n[   31.081971]  fbcon_init+0x538/0xc48\n[   31.082047]  visual_init+0x16c/0x23c\n[   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634\n[   31.082320]  do_take_over_console+0x24c/0x33c\n[   31.082429]  do_fbcon_takeover+0xbc/0x1b0\n[   31.082503]  fbcon_fb_registered+0x2d0/0x34c\n[   31.082663]  register_framebuffer+0x27c/0x38c\n[   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c\n[   31.082939]  drm_fb_helper_initial_config+0x50/0x74\n[   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108\n[   31.083115]  drm_client_register+0xa0/0xf4\n[   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc\n[   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0\n[   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0\n[   31.083616]  platform_probe+0x8c/0x13c\n[   31.083713]  really_probe+0x258/0x59c\n[   31.083793]  __driver_probe_device+0xc4/0x224\n[   31.083878]  driver_probe_device+0x70/0x1c0\n[   31.083961]  __device_attach_driver+0x108/0x1e0\n[   31.084052]  bus_for_each_drv+0x9c/0x100\n[   31.084125]  __device_attach+0x100/0x298\n[   31.084207]  device_initial_probe+0x14/0x20\n[   31.084292]  bus_probe_device+0xd8/0xdc\n[   31.084368]  deferred_probe_work_func+0x11c/0x180\n[   31.084451]  process_one_work+0x3ac/0x988\n[   31.084643]  worker_thread+0x398/0x694\n[   31.084752]  kthread+0x1bc/0x1c0\n[   31.084848]  ret_from_fork+0x10/0x20\n[   31.084932] irq event stamp: 64549\n[   31.084970] hardirqs last  enabled at (64548): [\u0026lt;ffffffc081adf35c\u0026gt;] _raw_spin_unlock_irqrestore+0x80/0x90\n[   31.085157]\n---truncated---(CVE-2024-35990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\r\n\r\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\r\n\r\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\r\n\r\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\r\n\r\nother info that might help us debug this:\r\n\r\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\r\n\r\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\n  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\n  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\n  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\n  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\n  rcu_do_batch kernel/rcu/tree.c:2196 [inline]\n  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\n  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n  __do_softirq kernel/softirq.c:588 [inline]\n  invoke_softirq kernel/softirq.c:428 [inline]\n  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\n  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649\n  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\n  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;(CVE-2024-36286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoundwire: cadence: fix invalid PDI offset\r\n\r\nFor some reason, we add an offset to the PDI, presumably to skip the\nPDI0 and PDI1 which are reserved for BPT.\r\n\r\nThis code is however completely wrong and leads to an out-of-bounds\naccess. We were just lucky so far since we used only a couple of PDIs\nand remained within the PDI array bounds.\r\n\r\nA Fixes: tag is not provided since there are no known platforms where\nthe out-of-bounds would be accessed, and the initial code had problems\nas well.\r\n\r\nA follow-up patch completely removes this useless offset.(CVE-2024-38635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: prevent pt_regs corruption for secondary idle threads\r\n\r\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\r\n\r\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\u0026quot;riscv: prevent stack corruption by reserving task_pt_regs(p) early\u0026quot;).\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.(CVE-2024-38667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\r\n\r\nIn nvmet_sq_destroy we capture sq-\u0026gt;ctrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u0026gt;sqs and sq-\u0026gt;ctrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\r\n\r\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u0026gt;ref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u0026gt;ctrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\r\n\r\nSolve this by re-capturing the sq-\u0026gt;ctrl after all inflight request has\ncompleted, where for sure sq-\u0026gt;ctrl reference is final, and move forward\nbased on that.\r\n\r\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.(CVE-2024-42152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexfat: fix potential deadlock on __exfat_get_dentry_set\r\n\r\nWhen accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array\nis allocated in __exfat_get_entry_set. The problem is that the bh-array is\nallocated with GFP_KERNEL. It does not make sense. In the following cases,\na deadlock for sbi-\u0026gt;s_lock between the two processes may occur.\r\n\r\n       CPU0                CPU1\n       ----                ----\n  kswapd\n   balance_pgdat\n    lock(fs_reclaim)\n                      exfat_iterate\n                       lock(\u0026amp;sbi-\u0026gt;s_lock)\n                       exfat_readdir\n                        exfat_get_uniname_from_ext_entry\n                         exfat_get_dentry_set\n                          __exfat_get_dentry_set\n                           kmalloc_array\n                            ...\n                            lock(fs_reclaim)\n    ...\n    evict\n     exfat_evict_inode\n      lock(\u0026amp;sbi-\u0026gt;s_lock)\r\n\r\nTo fix this, let\u0026apos;s allocate bh-array with GFP_NOFS.(CVE-2024-42315)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: virt_wifi: avoid reporting connection success with wrong SSID\r\n\r\nWhen user issues a connection with a different SSID than the one\nvirt_wifi has advertised, the __cfg80211_connect_result() will\ntrigger the warning: WARN_ON(bss_not_found).\r\n\r\nThe issue is because the connection code in virt_wifi does not\ncheck the SSID from user space (it only checks the BSSID), and\nvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS\neven if the SSID is different from the one virt_wifi has advertised.\nEventually cfg80211 won\u0026apos;t be able to find the cfg80211_bss and generate\nthe warning.\r\n\r\nFixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: prime: fix refcount underflow\r\n\r\nCalling nouveau_bo_ref() on a nouveau_bo without initializing it (and\nhence the backing ttm_bo) leads to a refcount underflow.\r\n\r\nInstead of calling nouveau_bo_ref() in the unwind path of\ndrm_gem_object_init(), clean things up manually.\r\n\r\n(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\r\n\r\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u0026gt;mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)\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\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n        1. In dwc3_gadget_suspend, there is a chance of a timeout when\n        moving the USB core to the halt state after clearing the\n        run/stop bit by software.\n        2. In dwc3_core_exit, the event buffer is cleared regardless of\n        the USB core\u0026apos;s status, which may lead to an SMMU faults and\n        other memory issues. if the USB core tries to access the event\n        buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software  when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\r\n\r\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \u0026quot;write\u0026quot; into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\r\n\r\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\r\n\r\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\r\n\r\nI tested this on SA8155P with Xen.(CVE-2024-46689)\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 read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (nct6775-core) 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-46757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: added NULL check at start of dc_validate_stream\r\n\r\n[Why]\nprevent invalid memory access\r\n\r\n[How]\ncheck if dc and stream are NULL(CVE-2024-46802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86: Acquire kvm-\u0026gt;srcu when handling KVM_SET_VCPU_EVENTS\r\n\r\nGrab kvm-\u0026gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly\nleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX\nreads guest memory.\r\n\r\nNote, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN\nvia sync_regs(), which already holds SRCU.  I.e. trying to precisely use\nkvm_vcpu_srcu_read_lock() around the problematic SMM code would cause\nproblems.  Acquiring SRCU isn\u0026apos;t all that expensive, so for simplicity,\ngrab it unconditionally for KVM_SET_VCPU_EVENTS.\r\n\r\n =============================\n WARNING: suspicious RCU usage\n 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!\r\n\r\n other info that might help us debug this:\r\n\r\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by repro/1071:\n  #0: ffff88811e424430 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]\r\n\r\n stack backtrace:\n CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  dump_stack_lvl+0x7f/0x90\n  lockdep_rcu_suspicious+0x13f/0x1a0\n  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]\n  kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]\n  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]\n  vmx_leave_nested+0x30/0x40 [kvm_intel]\n  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]\n  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]\n  ? mark_held_locks+0x49/0x70\n  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]\n  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  ? lock_acquire+0xba/0x2d0\n  ? find_held_lock+0x2b/0x80\n  ? do_user_addr_fault+0x40c/0x6f0\n  ? lock_release+0xb7/0x270\n  __x64_sys_ioctl+0x82/0xb0\n  do_syscall_64+0x6c/0x170\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7ff11eb1b539\n  \u0026lt;/TASK\u0026gt;(CVE-2024-46830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: nxp-fspi: fix the KASAN report out-of-bounds bug\r\n\r\nChange the memcpy length to fix the out-of-bounds issue when writing the\ndata that is not 4 byte aligned to TX FIFO.\r\n\r\nTo reproduce the issue, write 3 bytes data to NOR chip.\r\n\r\ndd if=3b of=/dev/mtd0\n[   36.926103] ==================================================================\n[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838\n[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455\n[   36.946721]\n[   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070\n[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)\n[   36.961260] Call trace:\n[   36.963723]  dump_backtrace+0x90/0xe8\n[   36.967414]  show_stack+0x18/0x24\n[   36.970749]  dump_stack_lvl+0x78/0x90\n[   36.974451]  print_report+0x114/0x5cc\n[   36.978151]  kasan_report+0xa4/0xf0\n[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28\n[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838\n[   36.990800]  spi_mem_exec_op+0x8ec/0xd30\n[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0\n[   36.999323]  spi_mem_dirmap_write+0x238/0x32c\n[   37.003710]  spi_nor_write_data+0x220/0x374\n[   37.007932]  spi_nor_write+0x110/0x2e8\n[   37.011711]  mtd_write_oob_std+0x154/0x1f0\n[   37.015838]  mtd_write_oob+0x104/0x1d0\n[   37.019617]  mtd_write+0xb8/0x12c\n[   37.022953]  mtdchar_write+0x224/0x47c\n[   37.026732]  vfs_write+0x1e4/0x8c8\n[   37.030163]  ksys_write+0xec/0x1d0\n[   37.033586]  __arm64_sys_write+0x6c/0x9c\n[   37.037539]  invoke_syscall+0x6c/0x258\n[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.046244]  do_el0_svc+0x44/0x5c\n[   37.049589]  el0_svc+0x38/0x78\n[   37.052681]  el0t_64_sync_handler+0x13c/0x158\n[   37.057077]  el0t_64_sync+0x190/0x194\n[   37.060775]\n[   37.062274] Allocated by task 455:\n[   37.065701]  kasan_save_stack+0x2c/0x54\n[   37.069570]  kasan_save_track+0x20/0x3c\n[   37.073438]  kasan_save_alloc_info+0x40/0x54\n[   37.077736]  __kasan_kmalloc+0xa0/0xb8\n[   37.081515]  __kmalloc_noprof+0x158/0x2f8\n[   37.085563]  mtd_kmalloc_up_to+0x120/0x154\n[   37.089690]  mtdchar_write+0x130/0x47c\n[   37.093469]  vfs_write+0x1e4/0x8c8\n[   37.096901]  ksys_write+0xec/0x1d0\n[   37.100332]  __arm64_sys_write+0x6c/0x9c\n[   37.104287]  invoke_syscall+0x6c/0x258\n[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.112972]  do_el0_svc+0x44/0x5c\n[   37.116319]  el0_svc+0x38/0x78\n[   37.119401]  el0t_64_sync_handler+0x13c/0x158\n[   37.123788]  el0t_64_sync+0x190/0x194\n[   37.127474]\n[   37.128977] The buggy address belongs to the object at ffff00081037c2a0\n[   37.128977]  which belongs to the cache kmalloc-8 of size 8\n[   37.141177] The buggy address is located 0 bytes inside of\n[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)\n[   37.153465]\n[   37.154971] The buggy address belongs to the physical page:\n[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c\n[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)\n[   37.175149] page_type: 0xfdffffff(slab)\n[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000\n[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000\n[   37.194553] page dumped because: kasan: bad access detected\n[   37.200144]\n[   37.201647] Memory state around the buggy address:\n[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc\n[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc\n[   37.220946] \u0026gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc\n[   37.228186]                                ^\n[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.246962] ==============================================================\n---truncated---(CVE-2024-46853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)\r\n\r\nErrata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0\n(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an\ninbound PCIe TLP spans more than two internal AXI 128-byte bursts,\nthe bus may corrupt the packet payload and the corrupt data may\ncause associated applications or the processor to hang.\r\n\r\nThe workaround for Errata #i2037 is to limit the maximum read\nrequest size and maximum payload size to 128 bytes. Add workaround\nfor Errata #i2037 here.\r\n\r\nThe errata and workaround is applicable only to AM65x SR 1.0 and\nlater versions of the silicon will have this fixed.\r\n\r\n[1] -\u0026gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared.  This causes page cache operations to\nhang waiting for the writeback flag.  For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp: check skb is non-NULL in tcp_rto_delta_us()  We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases:  Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u0026lt;48\u0026gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()  syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1)  Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put()  BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core net/core/dev.c:5661 [inline]   __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775   process_backlog+0x4ad/0xa50 net/core/dev.c:6108   __napi_poll+0xe7/0x980 net/core/dev.c:6772   napi_poll net/core/dev.c:6841 [inline]   net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963   handle_softirqs+0x1ce/0x800 kernel/softirq.c:554   __do_softirq+0x14/0x1a kernel/softirq.c:588   do_softirq+0x9a/0x100 kernel/softirq.c:455   __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382   local_bh_enable include/linux/bottom_half.h:33 [inline]   rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]   __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450   dev_queue_xmit include/linux/netdevice.h:3105 [inline]   neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565   neigh_output include/net/neighbour.h:542 [inline]   ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141   __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]   ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226   NF_HOOK_COND include/linux/netfilter.h:303 [inline]   ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247   dst_output include/net/dst.h:450 [inline]   NF_HOOK include/linux/netfilter.h:314 [inline]   ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366   inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135   __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]   tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143   tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333   __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679   inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750   __sys_connect_file net/socket.c:2061 [inline]   __sys_connect+0x606/0x690 net/socket.c:2078   __do_sys_connect net/socket.c:2088 [inline]   __se_sys_connect net/socket.c:2085 [inline]   __x64_sys_connect+0x91/0xe0 net/socket.c:2085   x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was stored to memory at:   nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: return -EINVAL when namelen is 0  When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered.  [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]  dump_stack+0x9a/0xd0 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  __kasan_report.cold+0x34/0x84 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  kasan_report+0x3a/0x50 [ T1205]  nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  ? nfsd4_release_lockowner+0x410/0x410 [ T1205]  cld_pipe_downcall+0x5ca/0x760 [ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]  ? down_write_killable_nested+0x170/0x170 [ T1205]  ? avc_policy_seqno+0x28/0x40 [ T1205]  ? selinux_file_permission+0x1b4/0x1e0 [ T1205]  rpc_pipe_write+0x84/0xb0 [ T1205]  vfs_write+0x143/0x520 [ T1205]  ksys_write+0xc9/0x170 [ T1205]  ? __ia32_sys_read+0x50/0x50 [ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]  do_syscall_64+0x33/0x40 [ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ==================================================================  Fix it by checking namelen.(CVE-2024-47692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds  In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-\u0026gt;s.con_num.  This commits resets the cid to clt_path-\u0026gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error  Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access.  dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue.  [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry().  syzbot reported a warning in bcm_release(). [0]  The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered.  However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release().  Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify().  [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  bcm_release+0x250/0x880 net/can/bcm.c:1578  __sock_release net/socket.c:659 [inline]  sock_close+0xbc/0x240 net/socket.c:1421  __fput+0x24a/0x8a0 fs/file_table.c:422  task_work_run+0x24f/0x310 kernel/task_work.c:228  exit_task_work include/linux/task_work.h:40 [inline]  do_exit+0xa2f/0x27f0 kernel/exit.c:882  do_group_exit+0x207/0x2c0 kernel/exit.c:1031  __do_sys_exit_group kernel/exit.c:1042 [inline]  __se_sys_exit_group kernel/exit.c:1040 [inline]  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160  \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  sock_map: Add a cond_resched() in sock_hash_free()  Several syzbot soft lockup reports all have in common sock_hash_free()  If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the  dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function.  This fix prevents a potential null pointer dereference error.  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed \u0026apos;mpc-\u0026gt;funcs-\u0026gt;set_output_gamma\u0026apos; could be null (see line 386)  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c     373 bool dcn30_set_output_transfer_func(struct dc *dc,     374                                 struct pipe_ctx *pipe_ctx,     375                                 const struct dc_stream_state *stream)     376 {     377         int mpcc_id = pipe_ctx-\u0026gt;plane_res.hubp-\u0026gt;inst;     378         struct mpc *mpc = pipe_ctx-\u0026gt;stream_res.opp-\u0026gt;ctx-\u0026gt;dc-\u0026gt;res_pool-\u0026gt;mpc;     379         const struct pwl_params *params = NULL;     380         bool ret = false;     381     382         /* program OGAM or 3DLUT only for the top pipe*/     383         if (pipe_ctx-\u0026gt;top_pipe == NULL) {     384                 /*program rmu shaper and 3dlut in MPC*/     385                 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);     386                 if (ret == false \u0026amp;\u0026amp; mpc-\u0026gt;funcs-\u0026gt;set_output_gamma) {                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL      387                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_HWPWL)     388                                 params = \u0026amp;stream-\u0026gt;out_transfer_func.pwl;     389                         else if (pipe_ctx-\u0026gt;stream-\u0026gt;out_transfer_func.type ==     390                                         TF_TYPE_DISTRIBUTED_POINTS \u0026amp;\u0026amp;     391                                         cm3_helper_translate_curve_to_hw_format(     392                                         \u0026amp;stream-\u0026gt;out_transfer_func,     393                                         \u0026amp;mpc-\u0026gt;blender_params, false))     394                                 params = \u0026amp;mpc-\u0026gt;blender_params;     395                          /* there are no ROM LUTs in OUTGAM */     396                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_PREDEFINED)     397                                 BREAK_TO_DEBUGGER();     398                 }     399         }     400 --\u0026gt; 401         mpc-\u0026gt;funcs-\u0026gt;set_output_gamma(mpc, mpcc_id, params);                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash      402         return ret;     403 }(CVE-2024-47720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled  Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold.  This was discovered through the lock debugging, and the corresponding log is as follows:  raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace:  warn_bogus_irq_restore+0x30/0x40  _raw_spin_unlock_irqrestore+0x84/0xc8  add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]  hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]  hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]  create_qp+0x138/0x258  ib_create_qp_kernel+0x50/0xe8  create_mad_qp+0xa8/0x128  ib_mad_port_open+0x218/0x448  ib_mad_init_device+0x70/0x1f8  add_client_context+0xfc/0x220  enable_device_and_get+0xd0/0x140  ib_register_device.part.0+0xf4/0x1c8  ib_register_device+0x34/0x50  hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]  hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]  __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]  hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: call cache_put if xdr_reserve_space returns NULL  If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get.  Reviwed-by: Jeff Layton \u0026lt;jlayton@kernel.org\u0026gt;(CVE-2024-47737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential oob read in nilfs_btree_check_delete()  The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries.  This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing/timerlat: Fix a race during cpuhp processing  There is another found exception that the \u0026quot;timerlat/1\u0026quot; thread was scheduled on CPU0, and lead to timer corruption finally:  ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace:  \u0026lt;TASK\u0026gt;  ? __warn+0x7c/0x110  ? debug_print_object+0x7d/0xb0  ? report_bug+0xf1/0x1d0  ? prb_read_valid+0x17/0x20  ? handle_bug+0x3f/0x70  ? exc_invalid_op+0x13/0x60  ? asm_exc_invalid_op+0x16/0x20  ? debug_print_object+0x7d/0xb0  ? debug_print_object+0x7d/0xb0  ? __pfx_timerlat_irq+0x10/0x10  __debug_object_init+0x110/0x150  hrtimer_init+0x1d/0x60  timerlat_main+0xab/0x2d0  ? __pfx_timerlat_main+0x10/0x10  kthread+0xb7/0xe0  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2d/0x40  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  \u0026lt;/TASK\u0026gt; ```  After tracing the scheduling event, it was discovered that the migration of the \u0026quot;timerlat/1\u0026quot; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU:  T1                       | T2 [CPUHP_ONLINE]           | cpu_device_down() osnoise_hotplug_workfn() |                          |     cpus_write_lock()                          |     takedown_cpu(1)                          |     cpus_write_unlock() [CPUHP_OFFLINE]          |     cpus_read_lock()     |     start_kthread(1)     |     cpus_read_unlock()   |  To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: wait for fixup workers before stopping cleaner kthread during umount  During unmount, at close_ctree(), we have the following steps in this order:  1) Park the cleaner kthread - this doesn\u0026apos;t destroy the kthread, it basically    halts its execution (wake ups against it work but do nothing);  2) We stop the cleaner kthread - this results in freeing the respective    struct task_struct;  3) We call btrfs_stop_all_workers() which waits for any jobs running in all    the work queues and then free the work queues.  Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don\u0026apos;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources.  Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs.  The stack traces reported by syzbot were the following:    BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065   Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52    CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024   Workqueue: btrfs-fixup btrfs_work_helper   Call Trace:    \u0026lt;TASK\u0026gt;    __dump_stack lib/dump_stack.c:94 [inline]    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120    print_address_description mm/kasan/report.c:377 [inline]    print_report+0x169/0x550 mm/kasan/report.c:488    kasan_report+0x143/0x180 mm/kasan/report.c:601    __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065    lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825    __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]    _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162    class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]    try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154    btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842    btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314    process_one_work kernel/workqueue.c:3229 [inline]    process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310    worker_thread+0x870/0xd30 kernel/workqueue.c:3391    kthread+0x2f0/0x390 kernel/kthread.c:389    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    \u0026lt;/TASK\u0026gt;    Allocated by task 2:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    unpoison_slab_object mm/kasan/common.c:319 [inline]    __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345    kasan_slab_alloc include/linux/kasan.h:247 [inline]    slab_post_alloc_hook mm/slub.c:4086 [inline]    slab_alloc_node mm/slub.c:4135 [inline]    kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187    alloc_task_struct_node kernel/fork.c:180 [inline]    dup_task_struct+0x57/0x8c0 kernel/fork.c:1107    copy_process+0x5d1/0x3d50 kernel/fork.c:2206    kernel_clone+0x223/0x880 kernel/fork.c:2787    kernel_thread+0x1bc/0x240 kernel/fork.c:2849    create_kthread kernel/kthread.c:412 [inline]    kthreadd+0x60d/0x810 kernel/kthread.c:765    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    Freed by task 61:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579    poison_slab_object mm/kasan/common.c:247 [inline]    __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264    kasan_slab_free include/linux/kasan.h:230 [inline]    slab_free_h ---truncated---(CVE-2024-49867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix a NULL pointer dereference when failed to start a new trasacntion  [BUG] Syzbot reported a NULL pointer dereference with the following crash:    FAULT_INJECTION: forcing a failure.    start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676    prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642    relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678   ...   BTRFS info (device loop0): balance: ended with status: -12   Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI   KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]   RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926   Call Trace:    \u0026lt;TASK\u0026gt;    commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496    btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430    del_balance_item fs/btrfs/volumes.c:3678 [inline]    reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742    btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574    btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673    vfs_ioctl fs/ioctl.c:51 [inline]    __do_sys_ioctl fs/ioctl.c:907 [inline]    __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893    do_syscall_x64 arch/x86/entry/common.c:52 [inline]    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83    entry_SYSCALL_64_after_hwframe+0x77/0x7f  [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-\u0026gt;balance_ctl to be NULL.  Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree.  However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume.  Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots().  That function checks if fs_info-\u0026gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-\u0026gt;reloc_ctl is NULL, it results a NULL pointer dereference.  [FIX] Just add extra check on fs_info-\u0026gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-\u0026gt;reloc_ctl-\u0026gt;merge_reloc_tree.  That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Initialize get_bytes_per_element\u0026apos;s default to 1  Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y \u0026amp; bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0.  This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in degamma hardware format translation  Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color  management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the  number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uninit-value access of new_ea in ea_buffer  syzbot reports that lzo1x_1_do_compress is using uninit-value:  ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178  ...  Uninit was stored to memory at:  ea_put fs/jfs/xattr.c:639 [inline]  ...  Local variable ea_buf created at:  __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662  __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934  =====================================================  The reason is ea_buf-\u0026gt;new_ea is not initialized properly.  Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: check if leafidx greater than num leaves per dmap tree  syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.  Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uaf in dbFreeBits  [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216  CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  __mutex_lock_common kernel/locking/mutex.c:587 [inline]  __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752  dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390  dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]  dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409  dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650  jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100  jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  Freed by task 5218:  kasan_save_stack mm/kasan/common.c:47 [inline]  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2252 [inline]  slab_free mm/slub.c:4473 [inline]  kfree+0x149/0x360 mm/slub.c:4594  dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278  jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247  jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454  reconfigure_super+0x445/0x880 fs/super.c:1083  vfs_cmd_reconfigure fs/fsopen.c:263 [inline]  vfs_fsconfig_locked fs/fsopen.c:292 [inline]  __do_sys_fsconfig fs/fsopen.c:473 [inline]  __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf.  Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/ioapic: Handle allocation failures gracefully  Breno observed panics when using failslab under certain conditions during runtime:     can not alloc irq_pin_list (-1,0,20)    Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed     panic+0x4e9/0x590    mp_irqdomain_alloc+0x9ab/0xa80    irq_domain_alloc_irqs_locked+0x25d/0x8d0    __irq_domain_alloc_irqs+0x80/0x110    mp_map_pin_to_irq+0x645/0x890    acpi_register_gsi_ioapic+0xe6/0x150    hpet_open+0x313/0x480  That\u0026apos;s a pointless panic which is a leftover of the historic IO/APIC code which panic\u0026apos;ed during early boot when the interrupt allocation failed.  The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode.  Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error  In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain:  ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace:  \u0026lt;TASK\u0026gt;  add_transaction_credits+0x5d1/0x5e0  start_this_handle+0x1ef/0x6a0  jbd2__journal_start+0x18b/0x340  ext4_dirty_inode+0x5d/0xb0  __mark_inode_dirty+0xe4/0x5d0  generic_update_time+0x60/0x70 [...] ============================================  So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways.  Note that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt when updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove unreasonable unlock in ocfs2_read_blocks  Patch series \u0026quot;Misc fixes for ocfs2_read_blocks\u0026quot;, v5.  This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks().  The second patch fixes an issue reported by Heming Zhao when reviewing above fix.   This patch (of 2):  There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: cancel dqi_sync_work before freeing oinfo  ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:  ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c  This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first.  BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 color transformation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSD: Limit the number of concurrent async COPY operations  Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector.  Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit.  An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy.  If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume  In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.  This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks.  Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: fnic: Move flush_work initialization out of if block  After commit 379a58caa199 (\u0026quot;scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\u0026quot;), it can happen that a work item is sent to an uninitialized work queue.  This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed.  The following warning is observed while the fnic driver is loaded:  kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel:  \u0026lt;IRQ\u0026gt; kernel:  queue_work_on+0x3a/0x50 kernel:  fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  __handle_irq_event_percpu+0x36/0x1a0 kernel:  handle_irq_event_percpu+0x30/0x70 kernel:  handle_irq_event+0x34/0x60 kernel:  handle_edge_irq+0x7e/0x1a0 kernel:  __common_interrupt+0x3b/0xb0 kernel:  common_interrupt+0x58/0xa0 kernel:  \u0026lt;/IRQ\u0026gt;  It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure.  This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: do not delay dst_entries_add() in dst_release()  dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy()  Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy()  dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already.  Decrementing the number of dsts must happen sooner.  Notes:  1) in CONFIG_XFRM case, dst_destroy() can call    dst_release_immediate(child), this might also cause UAF    if the child does not have DST_NOCOUNT set.    IPSEC maintainers might take a look and see how to address this.  2) There is also discussion about removing this count of dst,    which might happen in future kernels.(CVE-2024-50036)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()  On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog:  [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701]   ESR = 0x0000000096000007 [232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084]   SET = 0, FnV = 0 [232066.589216]   EA = 0, S1PTW = 0 [232066.589340]   FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683]   ISV = 0, ISS = 0x00000007 [232066.589842]   CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before dereferencing se  [WHAT \u0026amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)","status":"published","published":"2024-11-01T11:07:48Z","modified":"2026-08-18T01:18:37.533351967Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","level":"critical"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2024-2324","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\niommu/vt-d: Fix double list_add when enabling VMD in scalable mode\r\n\r\nWhen enabling VMD and IOMMU scalable mode, the following kernel panic\ncall trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids\nCPU) during booting:\r\n\r\npci 0000:59:00.5: Adding to iommu group 42\n...\nvmd 0000:59:00.5: PCI host bridge to bus 10000:80\npci 10000:80:01.0: [8086:352a] type 01 class 0x060400\npci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:01.0: enabling Extended Tags\npci 10000:80:01.0: PME# supported from D0 D3hot D3cold\npci 10000:80:01.0: DMAR: Setup RID2PASID failed\npci 10000:80:01.0: Failed to add to iommu group 42: -16\npci 10000:80:03.0: [8086:352b] type 01 class 0x060400\npci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:03.0: enabling Extended Tags\npci 10000:80:03.0: PME# supported from D0 D3hot D3cold\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:29!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7\nHardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022\nWorkqueue: events work_for_cpu_fn\nRIP: 0010:__list_add_valid.cold+0x26/0x3f\nCode: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f\n      0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1\n      fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9\n      9e e8 8b b1 fe\nRSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8\nRDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20\nRBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888\nR10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0\nR13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70\nFS:  0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n intel_pasid_alloc_table+0x9c/0x1d0\n dmar_insert_one_dev_info+0x423/0x540\n ? device_to_iommu+0x12d/0x2f0\n intel_iommu_attach_device+0x116/0x290\n __iommu_attach_device+0x1a/0x90\n iommu_group_add_device+0x190/0x2c0\n __iommu_probe_device+0x13e/0x250\n iommu_probe_device+0x24/0x150\n iommu_bus_notifier+0x69/0x90\n blocking_notifier_call_chain+0x5a/0x80\n device_add+0x3db/0x7b0\n ? arch_memremap_can_ram_remap+0x19/0x50\n ? memremap+0x75/0x140\n pci_device_add+0x193/0x1d0\n pci_scan_single_device+0xb9/0xf0\n pci_scan_slot+0x4c/0x110\n pci_scan_child_bus_extend+0x3a/0x290\n vmd_enable_domain.constprop.0+0x63e/0x820\n vmd_probe+0x163/0x190\n local_pci_probe+0x42/0x80\n work_for_cpu_fn+0x13/0x20\n process_one_work+0x1e2/0x3b0\n worker_thread+0x1c4/0x3a0\n ? rescuer_thread+0x370/0x370\n kthread+0xc7/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---\n...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\r\n\r\nThe following \u0026apos;lspci\u0026apos; output shows devices \u0026apos;10000:80:*\u0026apos; are subdevices of\nthe VMD device 0000:59:00.5:\r\n\r\n  $ lspci\n  ...\n  0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)\n  ...\n  10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)\n  10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)\n  10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)\n  10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)\n  10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]\n  10000:82:00\n---truncated---(CVE-2022-48916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  udf: Fix preallocation discarding at indirect extent boundary  When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.(CVE-2022-48946)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  PCI: mt7621: Add sentinel to quirks table  Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call.  This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in:  commit 7c18b64bba3b (\u0026quot;mips: ralink: mt7621: do not use kzalloc too early\u0026quot;)  Fix it by adding the required sentinel.(CVE-2022-48952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFC: nci: Bounds check struct nfc_target arrays  While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:    memcpy: detected field-spanning write (size 129) of single field \u0026quot;target-\u0026gt;sensf_res\u0026quot; at net/nfc/nci/ntf.c:260 (size 18)  This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.(CVE-2022-48967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  gpio: amd8111: Fix PCI device reference count leak  for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL.  If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the \u0026apos;out\u0026apos; label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the \u0026apos;Device not found\u0026apos; branch. For the normal path, add pci_dev_put() in amd_gpio_exit().(CVE-2022-48973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  can: af_can: fix NULL pointer dereference in can_rcv_filter  Analogue to commit 8aa59e355949 (\u0026quot;can: af_can: fix NULL pointer dereference in can_rx_register()\u0026quot;) we need to check for a missing initialization of ml_priv in the receive path of CAN frames.  Since commit 4e096a18867a (\u0026quot;net: introduce CAN specific pointer in the struct net_device\u0026quot;) the check for dev-\u0026gt;type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly.(CVE-2022-48977)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mm/gup: fix gup_pud_range() for dax  For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn\u0026apos;t depend on hugetlb. Commit 414fd080d125 (\u0026quot;mm/gup: fix gup_pmd_range() for dax\u0026quot;) fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well.  This fixes the below kernel panic:  general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP  \u0026lt; snip \u0026gt; Call Trace: \u0026lt;TASK\u0026gt; get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30 __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be  \u0026lt; snip \u0026gt; \u0026lt;/TASK\u0026gt; ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990  \u0026lt; snip \u0026gt; Kernel panic - not syncing: Fatal exception Kernel Offset: disabled(CVE-2022-48986)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  memcg: fix possible use-after-free in memcg_write_event_control()  memcg_write_event_control() accesses the dentry-\u0026gt;d_name of the specified control fd to route the write call.  As a cgroup interface file can\u0026apos;t be renamed, it\u0026apos;s safe to access d_name as long as the specified file is a regular cgroup file.  Also, as these cgroup interface files can\u0026apos;t be removed before the directory, it\u0026apos;s safe to access the parent too.  Prior to 347c4a874710 (\u0026quot;memcg: remove cgroup_event-\u0026gt;cft\u0026quot;), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses.  The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through.  With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free\u0026apos;s.  Fix the bug by resurrecting the file type check in __file_cft().  Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection.  Instead, let\u0026apos;s check the superblock and dentry type.(CVE-2022-48988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths  Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don\u0026apos;t keep accessing pages which aren\u0026apos;t mapped anymore.  Secondary MMUs don\u0026apos;t hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free.  I\u0026apos;m marking this as addressing an issue introduced in commit f3f0e1d2150b (\u0026quot;khugepaged: add support of collapse for tmpfs/shmem pages\u0026quot;), but most of the security impact of this only came in commit 27e1f8273113 (\u0026quot;khugepaged: enable collapse pmd for pte-mapped THP\u0026quot;), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.(CVE-2022-48991)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event  With clang\u0026apos;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed.  seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences.  This was found as a result of Clang\u0026apos;s new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.(CVE-2022-48994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing: Free buffers when a used dynamic event is removed(CVE-2022-49006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()  Syzbot reported a null-ptr-deref bug:   NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP  frequency \u0026lt; 30 seconds  general protection fault, probably for non-canonical address  0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN  KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]  CPU: 1 PID: 3603 Comm: segctord Not tainted  6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0  Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google  10/11/2022  RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0  fs/nilfs2/alloc.c:608  Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00  00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02  00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7  RSP: 0018:ffffc90003dff830 EFLAGS: 00010212  RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d  RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010  RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f  R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158  R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004  FS:  0000000000000000(0000) GS:ffff8880b9b00000(0000)  knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0  Call Trace:   \u0026lt;TASK\u0026gt;   nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline]   nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193   nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236   nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940   nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline]   nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline]   nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088   nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337   nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568   nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018   nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067   nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline]   nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline]   nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045   nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379   nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline]   nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570   kthread+0x2e4/0x3a0 kernel/kthread.c:376   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306   \u0026lt;/TASK\u0026gt;  ...  If DAT metadata file is corrupted on disk, there is a case where req-\u0026gt;pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end().  If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req-\u0026gt;pr_desc_bh and req-\u0026gt;pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash.  Fix this by adding a NULL check on req-\u0026gt;pr_desc_bh and req-\u0026gt;pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free().  This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations.(CVE-2022-49007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: ethernet: nixge: fix NULL dereference  In function nixge_hw_dma_bd_release() dereference of NULL pointer priv-\u0026gt;rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init().  Move for() loop with priv-\u0026gt;rx_bd_v dereference under the check for its validity.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-49019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails  Smatch report warning as follows:  drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn:   \u0026apos;\u0026amp;data-\u0026gt;list\u0026apos; not removed from list  If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data-\u0026gt;list will not be removed from driver_data.bmc_data, then list traversal may cause UAF.  Fix by removeing it from driver_data.bmc_data before free().(CVE-2022-49029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  libbpf: Handle size overflow for ringbuf mmap  The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t.  So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap.(CVE-2022-49030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()  Syzkaller reported BUG as follows:    BUG: sleeping function called from invalid context at        include/linux/sched/mm.h:274   Call Trace:    \u0026lt;TASK\u0026gt;    dump_stack_lvl+0xcd/0x134    __might_resched.cold+0x222/0x26b    kmem_cache_alloc+0x2e7/0x3c0    update_qgroup_limit_item+0xe1/0x390    btrfs_qgroup_inherit+0x147b/0x1ee0    create_subvol+0x4eb/0x1710    btrfs_mksubvol+0xfe5/0x13f0    __btrfs_ioctl_snap_create+0x2b0/0x430    btrfs_ioctl_snap_create_v2+0x25a/0x520    btrfs_ioctl+0x2a1c/0x5ce0    __x64_sys_ioctl+0x193/0x200    do_syscall_64+0x35/0x80  Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context.(CVE-2022-49033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: imon: fix access to invalid resource for the second interface\r\n\r\nimon driver probes two USB interfaces, and at the probe of the second\ninterface, the driver assumes blindly that the first interface got\nbound with the same imon driver.  It\u0026apos;s usually true, but it\u0026apos;s still\npossible that the first interface is bound with another driver via a\nmalformed descriptor.  Then it may lead to a memory corruption, as\nspotted by syzkaller; imon driver accesses the data from drvdata as\nstruct imon_context object although it\u0026apos;s a completely different one\nthat was assigned by another driver.\r\n\r\nThis patch adds a sanity check -- whether the first interface is\nreally bound with the imon driver or not -- for avoiding the problem\nabove at the probe time.(CVE-2023-52754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc2: fix possible NULL pointer dereference caused by driver concurrency\r\n\r\nIn _dwc2_hcd_urb_enqueue(), \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot; is executed without\nholding the lock \u0026quot;hsotg-\u0026gt;lock\u0026quot;. In _dwc2_hcd_urb_dequeue():\r\n\r\n    spin_lock_irqsave(\u0026amp;hsotg-\u0026gt;lock, flags);\n    ...\n\tif (!urb-\u0026gt;hcpriv) {\n\t\tdev_dbg(hsotg-\u0026gt;dev, \u0026quot;## urb-\u0026gt;hcpriv is NULL ##\\n\u0026quot;);\n\t\tgoto out;\n\t}\n    rc = dwc2_hcd_urb_dequeue(hsotg, urb-\u0026gt;hcpriv); // Use urb-\u0026gt;hcpriv\n    ...\nout:\n    spin_unlock_irqrestore(\u0026amp;hsotg-\u0026gt;lock, flags);\r\n\r\nWhen _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are\nconcurrently executed, the NULL check of \u0026quot;urb-\u0026gt;hcpriv\u0026quot; can be executed\nbefore \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot;. After urb-\u0026gt;hcpriv is NULL, it can be used\nin the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL\npointer dereference.\r\n\r\nThis possible bug is found by an experimental static analysis tool\ndeveloped by myself. This tool analyzes the locking APIs to extract\nfunction pairs that can be concurrently executed, and then analyzes the\ninstructions in the paired functions to identify possible concurrency\nbugs including data races and atomicity violations. The above possible\nbug is reported, when my tool analyzes the source code of Linux 6.5.\r\n\r\nTo fix this possible bug, \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot; should be executed with\nholding the lock \u0026quot;hsotg-\u0026gt;lock\u0026quot;. After using this patch, my tool never\nreports the possible bug, with the kernelconfiguration allyesconfig for\nx86_64. Because I have no associated hardware, I cannot test the patch\nin runtime testing, and just verify it according to the code logic.(CVE-2023-52855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()  The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: pci: cx23885: check cx23885_vdev_init() return  cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check.  Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfc: nci: fix possible NULL pointer dereference in send_acknowledge()  Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: Revert \u0026quot;scsi: fcoe: Fix potential deadlock on \u0026amp;fip-\u0026gt;ctlr_lock\u0026quot;\r\n\r\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\r\n\r\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \u0026quot;bh\u0026quot; to \u0026quot;irqsave\u0026quot;.\r\n\r\nInstead, a work queue should be used, and will be addressed in a separate\ncommit.(CVE-2024-26917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: prevent NULL pointer dereference in vsnprintf()\r\n\r\nIn of_modalias(), we can get passed the str and len parameters which would\ncause a kernel oops in vsnprintf() since it only allows passing a NULL ptr\nwhen the length is also 0. Also, we need to filter out the negative values\nof the len parameter as these will result in a really huge buffer since\nsnprintf() takes size_t parameter while ours is ssize_t...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the Svace static\nanalysis tool.(CVE-2024-35878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: xilinx_dpdma: Fix locking\r\n\r\nThere are several places where either chan-\u0026gt;lock or chan-\u0026gt;vchan.lock was\nnot held. Add appropriate locking. This fixes lockdep warnings like\r\n\r\n[   31.077578] ------------[ cut here ]------------\n[   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.077953] Modules linked in:\n[   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98\n[   31.078102] Hardware name: xlnx,zynqmp (DT)\n[   31.078169] Workqueue: events_unbound deferred_probe_work_func\n[   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0\n[   31.078550] sp : ffffffc083bb2e10\n[   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168\n[   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480\n[   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000\n[   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000\n[   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001\n[   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def\n[   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516\n[   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff\n[   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000\n[   31.080307] Call trace:\n[   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120\n[   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac\n[   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c\n[   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684\n[   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0\n[   31.081139]  commit_tail+0x234/0x294\n[   31.081246]  drm_atomic_helper_commit+0x1f8/0x210\n[   31.081363]  drm_atomic_commit+0x100/0x140\n[   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384\n[   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c\n[   31.081725]  drm_client_modeset_commit+0x34/0x5c\n[   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168\n[   31.081899]  drm_fb_helper_set_par+0x50/0x70\n[   31.081971]  fbcon_init+0x538/0xc48\n[   31.082047]  visual_init+0x16c/0x23c\n[   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634\n[   31.082320]  do_take_over_console+0x24c/0x33c\n[   31.082429]  do_fbcon_takeover+0xbc/0x1b0\n[   31.082503]  fbcon_fb_registered+0x2d0/0x34c\n[   31.082663]  register_framebuffer+0x27c/0x38c\n[   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c\n[   31.082939]  drm_fb_helper_initial_config+0x50/0x74\n[   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108\n[   31.083115]  drm_client_register+0xa0/0xf4\n[   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc\n[   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0\n[   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0\n[   31.083616]  platform_probe+0x8c/0x13c\n[   31.083713]  really_probe+0x258/0x59c\n[   31.083793]  __driver_probe_device+0xc4/0x224\n[   31.083878]  driver_probe_device+0x70/0x1c0\n[   31.083961]  __device_attach_driver+0x108/0x1e0\n[   31.084052]  bus_for_each_drv+0x9c/0x100\n[   31.084125]  __device_attach+0x100/0x298\n[   31.084207]  device_initial_probe+0x14/0x20\n[   31.084292]  bus_probe_device+0xd8/0xdc\n[   31.084368]  deferred_probe_work_func+0x11c/0x180\n[   31.084451]  process_one_work+0x3ac/0x988\n[   31.084643]  worker_thread+0x398/0x694\n[   31.084752]  kthread+0x1bc/0x1c0\n[   31.084848]  ret_from_fork+0x10/0x20\n[   31.084932] irq event stamp: 64549\n[   31.084970] hardirqs last  enabled at (64548): [\u0026lt;ffffffc081adf35c\u0026gt;] _raw_spin_unlock_irqrestore+0x80/0x90\n[   31.085157]\n---truncated---(CVE-2024-35990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\r\n\r\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\r\n\r\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\r\n\r\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\r\n\r\nother info that might help us debug this:\r\n\r\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n  #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\r\n\r\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\n  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\n  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\n  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\n  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\n  rcu_do_batch kernel/rcu/tree.c:2196 [inline]\n  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\n  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n  __do_softirq kernel/softirq.c:588 [inline]\n  invoke_softirq kernel/softirq.c:428 [inline]\n  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\n  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649\n  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\n  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;(CVE-2024-36286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoundwire: cadence: fix invalid PDI offset\r\n\r\nFor some reason, we add an offset to the PDI, presumably to skip the\nPDI0 and PDI1 which are reserved for BPT.\r\n\r\nThis code is however completely wrong and leads to an out-of-bounds\naccess. We were just lucky so far since we used only a couple of PDIs\nand remained within the PDI array bounds.\r\n\r\nA Fixes: tag is not provided since there are no known platforms where\nthe out-of-bounds would be accessed, and the initial code had problems\nas well.\r\n\r\nA follow-up patch completely removes this useless offset.(CVE-2024-38635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: prevent pt_regs corruption for secondary idle threads\r\n\r\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\r\n\r\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\u0026quot;riscv: prevent stack corruption by reserving task_pt_regs(p) early\u0026quot;).\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.(CVE-2024-38667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_check_dir_entry()\r\n\r\nThis adds sanity checks for ocfs2_dir_entry to make sure all members of\nocfs2_dir_entry don\u0026apos;t stray beyond valid memory region.(CVE-2024-41015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\r\n\r\nIn nvmet_sq_destroy we capture sq-\u0026gt;ctrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u0026gt;sqs and sq-\u0026gt;ctrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\r\n\r\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u0026gt;ref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u0026gt;ctrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\r\n\r\nSolve this by re-capturing the sq-\u0026gt;ctrl after all inflight request has\ncompleted, where for sure sq-\u0026gt;ctrl reference is final, and move forward\nbased on that.\r\n\r\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.(CVE-2024-42152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: virt_wifi: avoid reporting connection success with wrong SSID\r\n\r\nWhen user issues a connection with a different SSID than the one\nvirt_wifi has advertised, the __cfg80211_connect_result() will\ntrigger the warning: WARN_ON(bss_not_found).\r\n\r\nThe issue is because the connection code in virt_wifi does not\ncheck the SSID from user space (it only checks the BSSID), and\nvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS\neven if the SSID is different from the one virt_wifi has advertised.\nEventually cfg80211 won\u0026apos;t be able to find the cfg80211_bss and generate\nthe warning.\r\n\r\nFixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: prime: fix refcount underflow\r\n\r\nCalling nouveau_bo_ref() on a nouveau_bo without initializing it (and\nhence the backing ttm_bo) leads to a refcount underflow.\r\n\r\nInstead of calling nouveau_bo_ref() in the unwind path of\ndrm_gem_object_init(), clean things up manually.\r\n\r\n(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\r\n\r\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u0026gt;mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n        1. In dwc3_gadget_suspend, there is a chance of a timeout when\n        moving the USB core to the halt state after clearing the\n        run/stop bit by software.\n        2. In dwc3_core_exit, the event buffer is cleared regardless of\n        the USB core\u0026apos;s status, which may lead to an SMMU faults and\n        other memory issues. if the USB core tries to access the event\n        buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software  when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\r\n\r\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \u0026quot;write\u0026quot; into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\r\n\r\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\r\n\r\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\r\n\r\nI tested this on SA8155P with Xen.(CVE-2024-46689)\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 read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (nct6775-core) 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-46757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: added NULL check at start of dc_validate_stream\r\n\r\n[Why]\nprevent invalid memory access\r\n\r\n[How]\ncheck if dc and stream are NULL(CVE-2024-46802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86: Acquire kvm-\u0026gt;srcu when handling KVM_SET_VCPU_EVENTS\r\n\r\nGrab kvm-\u0026gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly\nleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX\nreads guest memory.\r\n\r\nNote, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN\nvia sync_regs(), which already holds SRCU.  I.e. trying to precisely use\nkvm_vcpu_srcu_read_lock() around the problematic SMM code would cause\nproblems.  Acquiring SRCU isn\u0026apos;t all that expensive, so for simplicity,\ngrab it unconditionally for KVM_SET_VCPU_EVENTS.\r\n\r\n =============================\n WARNING: suspicious RCU usage\n 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!\r\n\r\n other info that might help us debug this:\r\n\r\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by repro/1071:\n  #0: ffff88811e424430 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]\r\n\r\n stack backtrace:\n CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  dump_stack_lvl+0x7f/0x90\n  lockdep_rcu_suspicious+0x13f/0x1a0\n  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]\n  kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]\n  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]\n  vmx_leave_nested+0x30/0x40 [kvm_intel]\n  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]\n  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]\n  ? mark_held_locks+0x49/0x70\n  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]\n  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  ? lock_acquire+0xba/0x2d0\n  ? find_held_lock+0x2b/0x80\n  ? do_user_addr_fault+0x40c/0x6f0\n  ? lock_release+0xb7/0x270\n  __x64_sys_ioctl+0x82/0xb0\n  do_syscall_64+0x6c/0x170\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7ff11eb1b539\n  \u0026lt;/TASK\u0026gt;(CVE-2024-46830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: nxp-fspi: fix the KASAN report out-of-bounds bug\r\n\r\nChange the memcpy length to fix the out-of-bounds issue when writing the\ndata that is not 4 byte aligned to TX FIFO.\r\n\r\nTo reproduce the issue, write 3 bytes data to NOR chip.\r\n\r\ndd if=3b of=/dev/mtd0\n[   36.926103] ==================================================================\n[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838\n[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455\n[   36.946721]\n[   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070\n[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)\n[   36.961260] Call trace:\n[   36.963723]  dump_backtrace+0x90/0xe8\n[   36.967414]  show_stack+0x18/0x24\n[   36.970749]  dump_stack_lvl+0x78/0x90\n[   36.974451]  print_report+0x114/0x5cc\n[   36.978151]  kasan_report+0xa4/0xf0\n[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28\n[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838\n[   36.990800]  spi_mem_exec_op+0x8ec/0xd30\n[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0\n[   36.999323]  spi_mem_dirmap_write+0x238/0x32c\n[   37.003710]  spi_nor_write_data+0x220/0x374\n[   37.007932]  spi_nor_write+0x110/0x2e8\n[   37.011711]  mtd_write_oob_std+0x154/0x1f0\n[   37.015838]  mtd_write_oob+0x104/0x1d0\n[   37.019617]  mtd_write+0xb8/0x12c\n[   37.022953]  mtdchar_write+0x224/0x47c\n[   37.026732]  vfs_write+0x1e4/0x8c8\n[   37.030163]  ksys_write+0xec/0x1d0\n[   37.033586]  __arm64_sys_write+0x6c/0x9c\n[   37.037539]  invoke_syscall+0x6c/0x258\n[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.046244]  do_el0_svc+0x44/0x5c\n[   37.049589]  el0_svc+0x38/0x78\n[   37.052681]  el0t_64_sync_handler+0x13c/0x158\n[   37.057077]  el0t_64_sync+0x190/0x194\n[   37.060775]\n[   37.062274] Allocated by task 455:\n[   37.065701]  kasan_save_stack+0x2c/0x54\n[   37.069570]  kasan_save_track+0x20/0x3c\n[   37.073438]  kasan_save_alloc_info+0x40/0x54\n[   37.077736]  __kasan_kmalloc+0xa0/0xb8\n[   37.081515]  __kmalloc_noprof+0x158/0x2f8\n[   37.085563]  mtd_kmalloc_up_to+0x120/0x154\n[   37.089690]  mtdchar_write+0x130/0x47c\n[   37.093469]  vfs_write+0x1e4/0x8c8\n[   37.096901]  ksys_write+0xec/0x1d0\n[   37.100332]  __arm64_sys_write+0x6c/0x9c\n[   37.104287]  invoke_syscall+0x6c/0x258\n[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.112972]  do_el0_svc+0x44/0x5c\n[   37.116319]  el0_svc+0x38/0x78\n[   37.119401]  el0t_64_sync_handler+0x13c/0x158\n[   37.123788]  el0t_64_sync+0x190/0x194\n[   37.127474]\n[   37.128977] The buggy address belongs to the object at ffff00081037c2a0\n[   37.128977]  which belongs to the cache kmalloc-8 of size 8\n[   37.141177] The buggy address is located 0 bytes inside of\n[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)\n[   37.153465]\n[   37.154971] The buggy address belongs to the physical page:\n[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c\n[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)\n[   37.175149] page_type: 0xfdffffff(slab)\n[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000\n[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000\n[   37.194553] page dumped because: kasan: bad access detected\n[   37.200144]\n[   37.201647] Memory state around the buggy address:\n[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc\n[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc\n[   37.220946] \u0026gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc\n[   37.228186]                                ^\n[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.246962] ==============================================================\n---truncated---(CVE-2024-46853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)\r\n\r\nErrata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0\n(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an\ninbound PCIe TLP spans more than two internal AXI 128-byte bursts,\nthe bus may corrupt the packet payload and the corrupt data may\ncause associated applications or the processor to hang.\r\n\r\nThe workaround for Errata #i2037 is to limit the maximum read\nrequest size and maximum payload size to 128 bytes. Add workaround\nfor Errata #i2037 here.\r\n\r\nThe errata and workaround is applicable only to AM65x SR 1.0 and\nlater versions of the silicon will have this fixed.\r\n\r\n[1] -\u0026gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared.  This causes page cache operations to\nhang waiting for the writeback flag.  For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp: check skb is non-NULL in tcp_rto_delta_us()  We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases:  Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u0026lt;48\u0026gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()  syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1)  Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put()  BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core net/core/dev.c:5661 [inline]   __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775   process_backlog+0x4ad/0xa50 net/core/dev.c:6108   __napi_poll+0xe7/0x980 net/core/dev.c:6772   napi_poll net/core/dev.c:6841 [inline]   net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963   handle_softirqs+0x1ce/0x800 kernel/softirq.c:554   __do_softirq+0x14/0x1a kernel/softirq.c:588   do_softirq+0x9a/0x100 kernel/softirq.c:455   __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382   local_bh_enable include/linux/bottom_half.h:33 [inline]   rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]   __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450   dev_queue_xmit include/linux/netdevice.h:3105 [inline]   neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565   neigh_output include/net/neighbour.h:542 [inline]   ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141   __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]   ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226   NF_HOOK_COND include/linux/netfilter.h:303 [inline]   ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247   dst_output include/net/dst.h:450 [inline]   NF_HOOK include/linux/netfilter.h:314 [inline]   ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366   inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135   __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]   tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143   tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333   __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679   inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750   __sys_connect_file net/socket.c:2061 [inline]   __sys_connect+0x606/0x690 net/socket.c:2078   __do_sys_connect net/socket.c:2088 [inline]   __se_sys_connect net/socket.c:2085 [inline]   __x64_sys_connect+0x91/0xe0 net/socket.c:2085   x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was stored to memory at:   nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds  In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-\u0026gt;s.con_num.  This commits resets the cid to clt_path-\u0026gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error  Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access.  dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue.  [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry().  syzbot reported a warning in bcm_release(). [0]  The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered.  However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release().  Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify().  [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  bcm_release+0x250/0x880 net/can/bcm.c:1578  __sock_release net/socket.c:659 [inline]  sock_close+0xbc/0x240 net/socket.c:1421  __fput+0x24a/0x8a0 fs/file_table.c:422  task_work_run+0x24f/0x310 kernel/task_work.c:228  exit_task_work include/linux/task_work.h:40 [inline]  do_exit+0xa2f/0x27f0 kernel/exit.c:882  do_group_exit+0x207/0x2c0 kernel/exit.c:1031  __do_sys_exit_group kernel/exit.c:1042 [inline]  __se_sys_exit_group kernel/exit.c:1040 [inline]  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160  \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  sock_map: Add a cond_resched() in sock_hash_free()  Several syzbot soft lockup reports all have in common sock_hash_free()  If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the  dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function.  This fix prevents a potential null pointer dereference error.  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed \u0026apos;mpc-\u0026gt;funcs-\u0026gt;set_output_gamma\u0026apos; could be null (see line 386)  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c     373 bool dcn30_set_output_transfer_func(struct dc *dc,     374                                 struct pipe_ctx *pipe_ctx,     375                                 const struct dc_stream_state *stream)     376 {     377         int mpcc_id = pipe_ctx-\u0026gt;plane_res.hubp-\u0026gt;inst;     378         struct mpc *mpc = pipe_ctx-\u0026gt;stream_res.opp-\u0026gt;ctx-\u0026gt;dc-\u0026gt;res_pool-\u0026gt;mpc;     379         const struct pwl_params *params = NULL;     380         bool ret = false;     381     382         /* program OGAM or 3DLUT only for the top pipe*/     383         if (pipe_ctx-\u0026gt;top_pipe == NULL) {     384                 /*program rmu shaper and 3dlut in MPC*/     385                 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);     386                 if (ret == false \u0026amp;\u0026amp; mpc-\u0026gt;funcs-\u0026gt;set_output_gamma) {                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL      387                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_HWPWL)     388                                 params = \u0026amp;stream-\u0026gt;out_transfer_func.pwl;     389                         else if (pipe_ctx-\u0026gt;stream-\u0026gt;out_transfer_func.type ==     390                                         TF_TYPE_DISTRIBUTED_POINTS \u0026amp;\u0026amp;     391                                         cm3_helper_translate_curve_to_hw_format(     392                                         \u0026amp;stream-\u0026gt;out_transfer_func,     393                                         \u0026amp;mpc-\u0026gt;blender_params, false))     394                                 params = \u0026amp;mpc-\u0026gt;blender_params;     395                          /* there are no ROM LUTs in OUTGAM */     396                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_PREDEFINED)     397                                 BREAK_TO_DEBUGGER();     398                 }     399         }     400 --\u0026gt; 401         mpc-\u0026gt;funcs-\u0026gt;set_output_gamma(mpc, mpcc_id, params);                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash      402         return ret;     403 }(CVE-2024-47720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: call cache_put if xdr_reserve_space returns NULL  If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get.  Reviwed-by: Jeff Layton \u0026lt;jlayton@kernel.org\u0026gt;(CVE-2024-47737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential oob read in nilfs_btree_check_delete()  The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries.  This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing/timerlat: Fix a race during cpuhp processing  There is another found exception that the \u0026quot;timerlat/1\u0026quot; thread was scheduled on CPU0, and lead to timer corruption finally:  ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace:  \u0026lt;TASK\u0026gt;  ? __warn+0x7c/0x110  ? debug_print_object+0x7d/0xb0  ? report_bug+0xf1/0x1d0  ? prb_read_valid+0x17/0x20  ? handle_bug+0x3f/0x70  ? exc_invalid_op+0x13/0x60  ? asm_exc_invalid_op+0x16/0x20  ? debug_print_object+0x7d/0xb0  ? debug_print_object+0x7d/0xb0  ? __pfx_timerlat_irq+0x10/0x10  __debug_object_init+0x110/0x150  hrtimer_init+0x1d/0x60  timerlat_main+0xab/0x2d0  ? __pfx_timerlat_main+0x10/0x10  kthread+0xb7/0xe0  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2d/0x40  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  \u0026lt;/TASK\u0026gt; ```  After tracing the scheduling event, it was discovered that the migration of the \u0026quot;timerlat/1\u0026quot; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU:  T1                       | T2 [CPUHP_ONLINE]           | cpu_device_down() osnoise_hotplug_workfn() |                          |     cpus_write_lock()                          |     takedown_cpu(1)                          |     cpus_write_unlock() [CPUHP_OFFLINE]          |     cpus_read_lock()     |     start_kthread(1)     |     cpus_read_unlock()   |  To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: wait for fixup workers before stopping cleaner kthread during umount  During unmount, at close_ctree(), we have the following steps in this order:  1) Park the cleaner kthread - this doesn\u0026apos;t destroy the kthread, it basically    halts its execution (wake ups against it work but do nothing);  2) We stop the cleaner kthread - this results in freeing the respective    struct task_struct;  3) We call btrfs_stop_all_workers() which waits for any jobs running in all    the work queues and then free the work queues.  Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don\u0026apos;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources.  Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs.  The stack traces reported by syzbot were the following:    BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065   Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52    CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024   Workqueue: btrfs-fixup btrfs_work_helper   Call Trace:    \u0026lt;TASK\u0026gt;    __dump_stack lib/dump_stack.c:94 [inline]    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120    print_address_description mm/kasan/report.c:377 [inline]    print_report+0x169/0x550 mm/kasan/report.c:488    kasan_report+0x143/0x180 mm/kasan/report.c:601    __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065    lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825    __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]    _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162    class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]    try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154    btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842    btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314    process_one_work kernel/workqueue.c:3229 [inline]    process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310    worker_thread+0x870/0xd30 kernel/workqueue.c:3391    kthread+0x2f0/0x390 kernel/kthread.c:389    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    \u0026lt;/TASK\u0026gt;    Allocated by task 2:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    unpoison_slab_object mm/kasan/common.c:319 [inline]    __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345    kasan_slab_alloc include/linux/kasan.h:247 [inline]    slab_post_alloc_hook mm/slub.c:4086 [inline]    slab_alloc_node mm/slub.c:4135 [inline]    kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187    alloc_task_struct_node kernel/fork.c:180 [inline]    dup_task_struct+0x57/0x8c0 kernel/fork.c:1107    copy_process+0x5d1/0x3d50 kernel/fork.c:2206    kernel_clone+0x223/0x880 kernel/fork.c:2787    kernel_thread+0x1bc/0x240 kernel/fork.c:2849    create_kthread kernel/kthread.c:412 [inline]    kthreadd+0x60d/0x810 kernel/kthread.c:765    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    Freed by task 61:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579    poison_slab_object mm/kasan/common.c:247 [inline]    __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264    kasan_slab_free include/linux/kasan.h:230 [inline]    slab_free_h ---truncated---(CVE-2024-49867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix a NULL pointer dereference when failed to start a new trasacntion  [BUG] Syzbot reported a NULL pointer dereference with the following crash:    FAULT_INJECTION: forcing a failure.    start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676    prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642    relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678   ...   BTRFS info (device loop0): balance: ended with status: -12   Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI   KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]   RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926   Call Trace:    \u0026lt;TASK\u0026gt;    commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496    btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430    del_balance_item fs/btrfs/volumes.c:3678 [inline]    reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742    btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574    btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673    vfs_ioctl fs/ioctl.c:51 [inline]    __do_sys_ioctl fs/ioctl.c:907 [inline]    __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893    do_syscall_x64 arch/x86/entry/common.c:52 [inline]    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83    entry_SYSCALL_64_after_hwframe+0x77/0x7f  [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-\u0026gt;balance_ctl to be NULL.  Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree.  However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume.  Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots().  That function checks if fs_info-\u0026gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-\u0026gt;reloc_ctl is NULL, it results a NULL pointer dereference.  [FIX] Just add extra check on fs_info-\u0026gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-\u0026gt;reloc_ctl-\u0026gt;merge_reloc_tree.  That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: map the EBADMSG to nfserr_io to avoid warning  Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING.  Fix it by mapping EBADMSG to nfserr_io.  nfsd_buffered_readdir  iterate_dir // -EBADMSG -74   ext4_readdir // .iterate_shared    ext4_dx_readdir     ext4_htree_fill_tree      htree_dirblock_to_tree       ext4_read_dirblock        __ext4_read_dirblock         ext4_dirblock_csum_verify          warn_no_space_for_csum           __warn_no_space_for_csum         return ERR_PTR(-EFSBADCRC) // -EBADMSG -74  nfserrno // WARNING  [  161.115610] ------------[ cut here ]------------ [  161.116465] nfsd: non-standard errno: -74 [  161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [  161.118596] Modules linked in: [  161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [  161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [  161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [  161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6  05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [  161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [  161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [  161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [  161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [  161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [  161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [  161.135244] FS:  0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [  161.136695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [  161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [  161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [  161.141519] PKRU: 55555554 [  161.142076] Call Trace: [  161.142575]  ? __warn+0x9b/0x140 [  161.143229]  ? nfserrno+0x9d/0xd0 [  161.143872]  ? report_bug+0x125/0x150 [  161.144595]  ? handle_bug+0x41/0x90 [  161.145284]  ? exc_invalid_op+0x14/0x70 [  161.146009]  ? asm_exc_invalid_op+0x12/0x20 [  161.146816]  ? nfserrno+0x9d/0xd0 [  161.147487]  nfsd_buffered_readdir+0x28b/0x2b0 [  161.148333]  ? nfsd4_encode_dirent_fattr+0x380/0x380 [  161.149258]  ? nfsd_buffered_filldir+0xf0/0xf0 [  161.150093]  ? wait_for_concurrent_writes+0x170/0x170 [  161.151004]  ? generic_file_llseek_size+0x48/0x160 [  161.151895]  nfsd_readdir+0x132/0x190 [  161.152606]  ? nfsd4_encode_dirent_fattr+0x380/0x380 [  161.153516]  ? nfsd_unlink+0x380/0x380 [  161.154256]  ? override_creds+0x45/0x60 [  161.155006]  nfsd4_encode_readdir+0x21a/0x3d0 [  161.155850]  ? nfsd4_encode_readlink+0x210/0x210 [  161.156731]  ? write_bytes_to_xdr_buf+0x97/0xe0 [  161.157598]  ? __write_bytes_to_xdr_buf+0xd0/0xd0 [  161.158494]  ? lock_downgrade+0x90/0x90 [  161.159232]  ? nfs4svc_decode_voidarg+0x10/0x10 [  161.160092]  nfsd4_encode_operation+0x15a/0x440 [  161.160959]  nfsd4_proc_compound+0x718/0xe90 [  161.161818]  nfsd_dispatch+0x18e/0x2c0 [  161.162586]  svc_process_common+0x786/0xc50 [  161.163403]  ? nfsd_svc+0x380/0x380 [  161.164137]  ? svc_printk+0x160/0x160 [  161.164846]  ? svc_xprt_do_enqueue.part.0+0x365/0x380 [  161.165808]  ? nfsd_svc+0x380/0x380 [  161.166523]  ? rcu_is_watching+0x23/0x40 [  161.167309]  svc_process+0x1a5/0x200 [  161.168019]  nfsd+0x1f5/0x380 [  161.168663]  ? nfsd_shutdown_threads+0x260/0x260 [  161.169554]  kthread+0x1c4/0x210 [  161.170224]  ? kthread_insert_work_sanity_check+0x80/0x80 [  161.171246]  ret_from_fork+0x1f/0x30(CVE-2024-49875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in degamma hardware format translation  Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color  management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the  number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uninit-value access of new_ea in ea_buffer  syzbot reports that lzo1x_1_do_compress is using uninit-value:  ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178  ...  Uninit was stored to memory at:  ea_put fs/jfs/xattr.c:639 [inline]  ...  Local variable ea_buf created at:  __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662  __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934  =====================================================  The reason is ea_buf-\u0026gt;new_ea is not initialized properly.  Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: check if leafidx greater than num leaves per dmap tree  syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.  Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uaf in dbFreeBits  [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216  CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  __mutex_lock_common kernel/locking/mutex.c:587 [inline]  __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752  dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390  dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]  dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409  dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650  jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100  jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  Freed by task 5218:  kasan_save_stack mm/kasan/common.c:47 [inline]  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2252 [inline]  slab_free mm/slub.c:4473 [inline]  kfree+0x149/0x360 mm/slub.c:4594  dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278  jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247  jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454  reconfigure_super+0x445/0x880 fs/super.c:1083  vfs_cmd_reconfigure fs/fsopen.c:263 [inline]  vfs_fsconfig_locked fs/fsopen.c:292 [inline]  __do_sys_fsconfig fs/fsopen.c:473 [inline]  __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf.  Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/ioapic: Handle allocation failures gracefully  Breno observed panics when using failslab under certain conditions during runtime:     can not alloc irq_pin_list (-1,0,20)    Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed     panic+0x4e9/0x590    mp_irqdomain_alloc+0x9ab/0xa80    irq_domain_alloc_irqs_locked+0x25d/0x8d0    __irq_domain_alloc_irqs+0x80/0x110    mp_map_pin_to_irq+0x645/0x890    acpi_register_gsi_ioapic+0xe6/0x150    hpet_open+0x313/0x480  That\u0026apos;s a pointless panic which is a leftover of the historic IO/APIC code which panic\u0026apos;ed during early boot when the interrupt allocation failed.  The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode.  Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error  In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain:  ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace:  \u0026lt;TASK\u0026gt;  add_transaction_credits+0x5d1/0x5e0  start_this_handle+0x1ef/0x6a0  jbd2__journal_start+0x18b/0x340  ext4_dirty_inode+0x5d/0xb0  __mark_inode_dirty+0xe4/0x5d0  generic_update_time+0x60/0x70 [...] ============================================  So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways.  Note that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt when updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: cancel dqi_sync_work before freeing oinfo  ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:  ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c  This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first.  BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 color transformation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSD: Limit the number of concurrent async COPY operations  Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector.  Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit.  An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy.  If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume  In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.  This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks.  Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: asihpi: Fix potential OOB array access  ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware.  We shouldn\u0026apos;t trust it blindly.  This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: fnic: Move flush_work initialization out of if block  After commit 379a58caa199 (\u0026quot;scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\u0026quot;), it can happen that a work item is sent to an uninitialized work queue.  This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed.  The following warning is observed while the fnic driver is loaded:  kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel:  \u0026lt;IRQ\u0026gt; kernel:  queue_work_on+0x3a/0x50 kernel:  fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  __handle_irq_event_percpu+0x36/0x1a0 kernel:  handle_irq_event_percpu+0x30/0x70 kernel:  handle_irq_event+0x34/0x60 kernel:  handle_edge_irq+0x7e/0x1a0 kernel:  __common_interrupt+0x3b/0xb0 kernel:  common_interrupt+0x58/0xa0 kernel:  \u0026lt;/IRQ\u0026gt;  It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure.  This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: do not delay dst_entries_add() in dst_release()  dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy()  Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy()  dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already.  Decrementing the number of dsts must happen sooner.  Notes:  1) in CONFIG_XFRM case, dst_destroy() can call    dst_release_immediate(child), this might also cause UAF    if the child does not have DST_NOCOUNT set.    IPSEC maintainers might take a look and see how to address this.  2) There is also discussion about removing this count of dst,    which might happen in future kernels.(CVE-2024-50036)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before dereferencing se  [WHAT \u0026amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)","status":"published","published":"2024-11-01T11:07:48Z","modified":"2026-08-18T01:17:36.430422624Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H","level":"critical"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2025-2802","title":"kernel security update","description":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: Fix uninit-value in nci_rx_work\n\nsyzbot reported the following uninit-value access issue [1]\n\nnci_rx_work() parses received packet from ndev-\u0026gt;rx_q. It should be\nvalidated header size, payload size and total packet size before\nprocessing the packet. If an invalid packet is detected, it should be\nsilently discarded.(CVE-2024-38381)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()In the prueth_probe() function, if one of the calls to emac_phy_connect()fails due to of_phy_connect() returning NULL, then the subsequent call tophy_attached_info() will dereference a NULL pointer.Check the return code of emac_phy_connect and fail cleanly if there is anerror.(CVE-2024-38584)\n\nIn the Linux kernel, the following vulnerability has been resolved:cpufreq: exit() callback is optionalThe exit() callback is optional and shouldn t be called without checkinga valid pointer first.Also, we must clear freq_table pointer even if the exit() callback isn tpresent.(CVE-2024-38615)\n\nIn the Linux kernel, the following vulnerability has been resolved:serial: max3100: Update uart_driver_registered on driver removalThe removal of the last MAX3100 device triggers the removal ofthe driver. However, code doesn t update the respective globalvariable and after insmod — rmmod — insmod cycle the kerneloopses:  max3100 spi-PRP0001:01: max3100_probe: adding port 0  BUG: kernel NULL pointer dereference, address: 0000000000000408  ...  RIP: 0010:serial_core_register_port+0xa0/0x840  ...   max3100_probe+0x1b6/0x280 [max3100]   spi_probe+0x8d/0xb0Update the actual state so next time UART driver will be registeredagain.Hugo also noticed, that the error path in the probe also affectedby having the variable set, and not cleared. Instead of clearing itmove the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nenic: Validate length of nl attributes in enic_set_vf_port\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:riscv: prevent pt_regs corruption for secondary idle threadsTop of the kernel thread stack should be reserved for pt_regs. Howeverthis is not the case for the idle threads of the secondary boot harts.Their stacks overlap with their pt_regs, so both may get corrupted.Similar issue has been fixed for the primary hart, see c7cdd96eca28( riscv: prevent stack corruption by reserving task_pt_regs(p) early ).However that fix was not propagated to the secondary harts. The problemhas been noticed in some CPU hotplug tests with V enabled. The functionsmp_callin stored several registers on stack, corrupting top of pt_regsstructure including status field. As a result, kernel attempted to saveor restore inexistent V context.(CVE-2024-38667)\n\nIn the Linux kernel, the following vulnerability has been resolved:jfs: xattr: fix buffer overflow for invalid xattrWhen an xattr size is not what is expected, it is printed out to thekernel log in hex format as a form of debugging.  But when that xattrsize is bigger than the expected size, printing it out can cause anaccess off the end of the buffer.Fix this all up by properly restricting the size of the debug hex dumpin the kernel log.(CVE-2024-40902)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages\n\nThe syzbot fuzzer found that the interrupt-URB completion callback in\nthe cdc-wdm driver was taking too long, and the driver\u0026apos;s immediate\nresubmission of interrupt URBs with -EPROTO status combined with the\ndummy-hcd emulation to cause a CPU lockup:\n\ncdc_wdm 1-1:1.0: nonzero urb status received: -71\ncdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes\nwatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]\nCPU#0 Utilization every 4s during lockup:\n\t#1:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#2:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#3:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#4:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#5:  98% system,\t  1% softirq,\t  3% hardirq,\t  0% idle\nModules linked in:\nirq event stamp: 73096\nhardirqs last  enabled at (73095): [\u0026lt;ffff80008037bc00\u0026gt;] console_emit_next_record kernel/printk/printk.c:2935 [inline]\nhardirqs last  enabled at (73095): [\u0026lt;ffff80008037bc00\u0026gt;] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994\nhardirqs last disabled at (73096): [\u0026lt;ffff80008af10b00\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\nhardirqs last disabled at (73096): [\u0026lt;ffff80008af10b00\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\nsoftirqs last  enabled at (73048): [\u0026lt;ffff8000801ea530\u0026gt;] softirq_handle_end kernel/softirq.c:400 [inline]\nsoftirqs last  enabled at (73048): [\u0026lt;ffff8000801ea530\u0026gt;] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582\nsoftirqs last disabled at (73043): [\u0026lt;ffff800080020de8\u0026gt;] __do_softirq+0x14/0x20 kernel/softirq.c:588\nCPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n\nTesting showed that the problem did not occur if the two error\nmessages -- the first two lines above -- were removed; apparently adding\nmaterial to the kernel log takes a surprisingly large amount of time.\n\nIn any case, the best approach for preventing these lockups and to\navoid spamming the log with thousands of error messages per second is\nto ratelimit the two dev_err() calls.  Therefore we replace them with\ndev_err_ratelimited().(CVE-2024-40904)\n\nIn the Linux kernel, the following vulnerability has been resolved:nvmet: always initialize cqe.resultThe spec doesn t mandate that the first two double words (aka results)for the command queue entry need to be set to 0 when they are notused (not specified). Though, the target implemention returns 0 for TCPand FC but not for RDMA.Let s make RDMA behave the same and thus explicitly initializing theresult field. This prevents leaking any data from the stack.(CVE-2024-41079)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/nouveau: fix null pointer dereference in nouveau_connector_get_modesIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a possible NULL pointerdereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42101)\n\nIn the Linux kernel, the following vulnerability has been resolved:Revert  mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Patch series  mm: Avoid possible overflows in dirty throttling .Dirty throttling logic assumes dirty limits in page units fit into32-bits.  This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways.  Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh \u0026gt;= 1\u0026lt;\u0026lt;32 (which is actually common - thedefault settings with 4GB of RAM will trigger this).  Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs.  We havediv64_ul() in case we want to be safe \u0026amp; cheap.  Thirdly, if dirtythresholds are larger than 1\u0026lt;\u0026lt;32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)\n\nIn the Linux kernel, the following vulnerability has been resolved:Revert  sched/fair: Make sure to try to detach at least one movable task This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.b0defa7ae03ec changed the load balancing logic to ignore env.max_loop ifall tasks examined to that point were pinned. The goal of the patch wasto make it more likely to be able to detach a task buried in a long listof pinned tasks. However, this has the unfortunate side effect ofcreating an O(n) iteration in detach_tasks(), as we now must fullyiterate every task on a cpu if all or most are pinned. Since this loadbalance code is done with rq lock held, and often in softirq context, itis very easy to trigger hard lockups. We observed such hard lockups witha user who affined O(10k) threads to a single cpu.When I discussed this with Vincent he initially suggested that we keepthe limit on the number of tasks to detach, but increase the number oftasks we can search. However, after some back and forth on the mailinglist, he recommended we instead revert the original patch, as it seemslikely no one was actually getting hit by the original issue.(CVE-2024-42245)\n\nIn the Linux kernel, the following vulnerability has been resolved:wireguard: allowedips: avoid unaligned 64-bit memory accessesOn the parisc platform, the kernel issues kernel warnings becauseswap_endian() tries to load a 128-bit IPv6 address from an unalignedmemory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)Avoid such unaligned memory accesses by instead using theget_unaligned_be64() helper macro.[Jason: replace src[8] in original patch with src+8](CVE-2024-42247)\n\nIn the Linux kernel, the following vulnerability has been resolved:f2fs: fix to don t dirty inode for readonly filesystemsyzbot reports f2fs bug as below:kernel BUG at fs/f2fs/inode.c:933!RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6bThe root cause is:- do_sys_open - f2fs_lookup  - __f2fs_find_entry   - f2fs_i_depth_write    - f2fs_mark_inode_dirty_sync     - f2fs_dirty_inode      - set_inode_flag(inode, FI_DIRTY_INODE)- umount - kill_f2fs_super  - kill_block_super   - generic_shutdown_super    - sync_filesystem    : sb is readonly, skip sync_filesystem()    - evict_inodes     - iput      - f2fs_evict_inode       - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))       : trigger kernel panicWhen we try to repair i_current_depth in readonly filesystem, let sskip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)\n\nIn the Linux kernel, the following vulnerability has been resolved:vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()Since commit 3f8ca2e115e5 ( vhost/scsi: Extract common handling codefrom control queue handler ) a null pointer dereference bug can betriggered when guest sends an SCSI AN request.In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with`\u0026amp;v_req.tmf.lun[1]` within a switch-case block and is then passed tovhost_scsi_get_req() which extracts `vc-\u0026gt;req` and `tpg`. However, fora `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` isset to NULL in this branch. Later, in vhost_scsi_get_req(),`vc-\u0026gt;target` is dereferenced without being checked, leading to a nullpointer dereference bug. This bug can be triggered from guest.When this bug occurs, the vhost_worker process is killed while holding`vq-\u0026gt;mutex` and the corresponding tpg will remain occupiedindefinitely.Below is the KASAN report:Oops: general protection fault, probably for non-canonical address0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:vhost_scsi_get_req+0x165/0x3a0Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 0048 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 \u0026lt;0f\u0026gt; b604 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00RSP: 0018:ffff888017affb50 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000FS:  000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0Call Trace: \u0026lt;TASK\u0026gt; ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350... \u0026lt;/TASK\u0026gt;---[ end trace 0000000000000000 ]---Let s add a check in vhost_scsi_get_req.[whitespace fixes](CVE-2024-49863)\n\nIn the Linux kernel, the following vulnerability has been resolved:nfsd: map the EBADMSG to nfserr_io to avoid warningExt4 will throw -EBADMSG through ext4_readdir when a checksum erroroccurs, resulting in the following WARNING.Fix it by mapping EBADMSG to nfserr_io.nfsd_buffered_readdir iterate_dir // -EBADMSG -74  ext4_readdir // .iterate_shared   ext4_dx_readdir    ext4_htree_fill_tree     htree_dirblock_to_tree      ext4_read_dirblock       __ext4_read_dirblock        ext4_dirblock_csum_verify         warn_no_space_for_csum          __warn_no_space_for_csum        return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING[  161.115610] ------------[ cut here ]------------[  161.116465] nfsd: non-standard errno: -74[  161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0[  161.118596] Modules linked in:[  161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138[  161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[  161.123601] RIP: 0010:nfserrno+0x9d/0xd0[  161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33[  161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286[  161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[  161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a[  161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827[  161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021[  161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8[  161.135244] FS:  0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000[  161.136695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[  161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0[  161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[  161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[  161.141519] PKRU: 55555554[  161.142076] Call Trace:[  161.142575]  ? __warn+0x9b/0x140[  161.143229]  ? nfserrno+0x9d/0xd0[  161.143872]  ? report_bug+0x125/0x150[  161.144595]  ? handle_bug+0x41/0x90[  161.145284]  ? exc_invalid_op+0x14/0x70[  161.146009]  ? asm_exc_invalid_op+0x12/0x20[  161.146816]  ? nfserrno+0x9d/0xd0[  161.147487]  nfsd_buffered_readdir+0x28b/0x2b0[  161.148333]  ? nfsd4_encode_dirent_fattr+0x380/0x380[  161.149258]  ? nfsd_buffered_filldir+0xf0/0xf0[  161.150093]  ? wait_for_concurrent_writes+0x170/0x170[  161.151004]  ? generic_file_llseek_size+0x48/0x160[  161.151895]  nfsd_readdir+0x132/0x190[  161.152606]  ? nfsd4_encode_dirent_fattr+0x380/0x380[  161.153516]  ? nfsd_unlink+0x380/0x380[  161.154256]  ? override_creds+0x45/0x60[  161.155006]  nfsd4_encode_readdir+0x21a/0x3d0[  161.155850]  ? nfsd4_encode_readlink+0x210/0x210[  161.156731]  ? write_bytes_to_xdr_buf+0x97/0xe0[  161.157598]  ? __write_bytes_to_xdr_buf+0xd0/0xd0[  161.158494]  ? lock_downgrade+0x90/0x90[  161.159232]  ? nfs4svc_decode_voidarg+0x10/0x10[  161.160092]  nfsd4_encode_operation+0x15a/0x440[  161.160959]  nfsd4_proc_compound+0x718/0xe90[  161.161818]  nfsd_dispatch+0x18e/0x2c0[  161.162586]  svc_process_common+0x786/0xc50[  161.163403]  ? nfsd_svc+0x380/0x380[  161.164137]  ? svc_printk+0x160/0x160[  161.164846]  ? svc_xprt_do_enqueue.part.0+0x365/0x380[  161.165808]  ? nfsd_svc+0x380/0x380[  161.166523]  ? rcu_is_watching+0x23/0x40[  161.167309]  svc_process+0x1a5/0x200[  161.168019]  nfsd+0x1f5/0x380[  161.168663]  ? nfsd_shutdown_threads+0x260/0x260[  161.169554]  kthread+0x1c4/0x210[  161.170224]  ? kthread_insert_work_sanity_check+0x80/0x80[  161.171246]  ret_from_fork+0x1f/0x30(CVE-2024-49875)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index out of bounds in degamma hardware format translationFixes index out of bounds issue in`cm_helper_translate_curve_to_degamma_hw_format` function. The issuecould occur when the index  i  exceeds the number of transfer functionpoints (TRANSFER_FUNC_POINTS).The fix adds a check to ensure  i  is within bounds before accessing thetransfer function points. If  i  is out of bounds the function returnsfalse to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow  output_tf-\u0026gt;tf_pts.red  1025 \u0026lt;= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow  output_tf-\u0026gt;tf_pts.green  1025 \u0026lt;= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow  output_tf-\u0026gt;tf_pts.blue  1025 \u0026lt;= s32max(CVE-2024-49894)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for  afb  in amdgpu_dm_plane_handle_cursor_update (v2)This commit adds a null check for the  afb  variable in theamdgpu_dm_plane_handle_cursor_update function. Previously,  afb  wasassumed to be null, but was used later in the code without a null check.This could potentially lead to a null pointer dereference.Changes since v1:- Moved the null check for  afb  to the line where  afb  is used. (Alex)Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed  afb  could be null (see line 1252)(CVE-2024-49905)\n\nIn the Linux kernel, the following vulnerability has been resolved:fbdev: efifb: Register sysfs groups through driver coreThe driver core can register and cleanup sysfs groups already.Make use of that functionality to simplify the error handling andcleanup.Also avoid a UAF race during unregistering where the sysctl attributeswere usable after the info struct was freed.(CVE-2024-49925)\n\nIn the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix array out-of-bound access in SoC statsCurrently, the ath11k_soc_dp_stats::hal_reo_error array is defined with amaximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx()function access ath11k_soc_dp_stats::hal_reo_error using the REOdestination SRNG ring ID, which is incorrect. SRNG ring ID differ fromnormal ring ID, and this usage leads to out-of-bounds array access. To fixthis issue, modify ath11k_dp_process_rx() to use the normal ring IDdirectly instead of the SRNG ring ID to avoid out-of-bounds array access.Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-49930)\n\nIn the Linux kernel, the following vulnerability has been resolved:ACPI: PAD: fix crash in exit_round_robin()The kernel occasionally crashes in cpumask_clear_cpu(), which is calledwithin exit_round_robin(), because when executing clear_bit(nr, addr) withnr set to 0xffffffff, the address calculation may cause misalignment withinthe memory, leading to access to an invalid memory address.----------BUG: unable to handle kernel paging request at ffffffffe0740618        ...CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G           OE  X --------- -  - 4.18.0-425.19.2.el8_7.x86_64 #1        ...RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 \u0026lt;f0\u0026gt; 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000eR13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000eFS:  0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40        ...CR2: ffffffffe0740618crash\u0026gt; dis -lr ffffffffc0726923        .../usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 1140xffffffffc0726918 \u0026lt;power_saving_thread+776\u0026gt;: mov    %r12d,%r12d/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 3250xffffffffc072691b \u0026lt;power_saving_thread+779\u0026gt;: mov    -0x3f8d7de0(,%r12,4),%eax/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 800xffffffffc0726923 \u0026lt;power_saving_thread+787\u0026gt;: lock btr %rax,0x19cf4(%rip)        # 0xffffffffc0740620 \u0026lt;pad_busy_cpus_bits\u0026gt;crash\u0026gt; px tsk_in_cpu[14]$66 = 0xffffffffcrash\u0026gt; px 0xffffffffc072692c+0x19cf4$99 = 0xffffffffc0740620crash\u0026gt; sym 0xffffffffc0740620ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]crash\u0026gt; px pad_busy_cpus_bits[0]$42 = 0xfffc0----------To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before callingcpumask_clear_cpu() in exit_round_robin(), just as it is done inround_robin_cpu().[ rjw: Subject edit, avoid updates to the same value ](CVE-2024-49935)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: add more sanity checks to qdisc_pkt_len_init()One path takes care of SKB_GSO_DODGY, assumingskb-\u0026gt;len is bigger than hdr_len.virtio_net_hdr_to_skb() does not fully dissect TCP headers,it only make sure it is at least 20 bytes.It is possible for an user to provide a malicious  GSO  packet,total length of 80 bytes.- 20 bytes of IPv4 header- 60 bytes TCP header- a small gso_size like 8virtio_net_hdr_to_skb() would declare this packet as a normalGSO packet, because it would see 40 bytes of payload,bigger than gso_size.We need to make detect this case to not underflowqdisc_skb_cb(skb)-\u0026gt;pkt_len.(CVE-2024-49948)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: avoid potential underflow in qdisc_pkt_len_init() with UFOAfter commit 7c6d2ecbda83 ( net: be more gentle about silly gsorequests coming from user ) virtio_net_hdr_to_skb() had sanity checkto detect malicious attempts from user space to cook a bad GSO packet.Then commit cf9acc90c80ec ( net: virtio_net_hdr_to_skb: counttransport header in UFO ) while fixing one issue, allowed user spaceto cook a GSO packet with the following characteristic :IPv4 SKB_GSO_UDP, gso_size=3, skb-\u0026gt;len = 28.When this packet arrives in qdisc_pkt_len_init(), we end upwith hdr_len = 28 (IPv4 header + UDP header), matching skb-\u0026gt;lenThen the following sets gso_segs to 0 :gso_segs = DIV_ROUND_UP(skb-\u0026gt;len - hdr_len,                        shinfo-\u0026gt;gso_size);Then later we set qdisc_skb_cb(skb)-\u0026gt;pkt_len to back to zero :/qdisc_skb_cb(skb)-\u0026gt;pkt_len += (gso_segs - 1) * hdr_len;This leads to the following crash in fq_codel [1]qdisc_pkt_len_init() is best effort, we only want an estimationof the bytes sent on the wire, not crashing the kernel.This patch is fixing this particular issue, a following oneadds more sanity checks for another potential bug.[1][   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000[   70.724561] #PF: supervisor read access in kernel mode[   70.724561] #PF: error_code(0x0000) - not-present page[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0[   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI[   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991[   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 \u0026lt;49\u0026gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49All code========   0: 24 08                 and    $0x8,%al   2: 49 c1 e1 06           shl    $0x6,%r9   6: 44 89 7c 24 18        mov    %r15d,0x18(%rsp)   b: 45 31 ed              xor    %r13d,%r13d   e: 45 31 c0              xor    %r8d,%r8d  11: 31 ff                 xor    %edi,%edi  13: 89 44 24 14           mov    %eax,0x14(%rsp)  17: 4c 03 8b 90 01 00 00  add    0x190(%rbx),%r9  1e: eb 04                 jmp    0x24  20: 39 ca                 cmp    %ecx,%edx  22: 73 37                 jae    0x5b  24: 4d 8b 39              mov    (%r9),%r15  27: 83 c7 01              add    $0x1,%edi  2a:* 49 8b 17              mov    (%r15),%rdx  \u0026lt;-- trapping instruction  2d: 49 89 11              mov    %rdx,(%r9)  30: 41 8b 57 28           mov    0x28(%r15),%edx  34: 45 8b 5f 34           mov    0x34(%r15),%r11d  38: 49 c7 07 00 00 00 00  movq   $0x0,(%r15)  3f: 49                    rex.WBCode starting with the faulting instruction===========================================   0: 49 8b 17              mov    (%r15),%rdx   3: 49 89 11              mov    %rdx,(%r9)   6: 41 8b 57 28           mov    0x28(%r15),%edx   a: 45 8b 5f 34           mov    0x34(%r15),%r11d   e: 49 c7 07 00 00 00 00  movq   $0x0,(%r15)  15: 49                    rex.WB[   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202[   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000[   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001[   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000[   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58[   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000[   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000[   70.724561] CS:  0010 DS: 0000 ES: 0000 C---truncated---(CVE-2024-49949)\n\nIn the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix uaf in l2cap_connect[Syzbot reported]BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Workqueue: hci2 hci_rx_workCall Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244...Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-49950)\n\nIn the Linux kernel, the following vulnerability has been resolved:ocfs2: fix null-ptr-deref when journal load failed.During the mounting process, if journal_reset() fails because of too shortjournal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() callsjbd2_journal_flush()-\u0026gt;jbd2_cleanup_journal_tail()-\u0026gt;__jbd2_update_log_tail()-\u0026gt;jbd2_journal_update_sb_log_tail()-\u0026gt;lock_buffer(journal-\u0026gt;j_sb_buffer), resulting in a null-pointerdereference error.To resolve this issue, we should check the JBD2_LOADED flag to ensure thejournal was properly loaded.  Additionally, use journal instead ofosb-\u0026gt;journal directly to simplify the code.(CVE-2024-49957)\n\nIn the Linux kernel, the following vulnerability has been resolved:ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will causeNULL pointer dereference later.[ rjw: Subject and changelog edits ](CVE-2024-49962)\n\nIn the Linux kernel, the following vulnerability has been resolved:static_call: Handle module init failure correctly in static_call_del_module()Module insertion invokes static_call_add_module() to initialize the staticcalls in a module. static_call_add_module() invokes __static_call_init(),which allocates a struct static_call_mod to either encapsulate the built-instatic call sites of the associated key into it so further modules can beadded or to append the module to the module chain.If that allocation fails the function returns with an error code and themodule core invokes static_call_del_module() to clean up eventually addedstatic_call_mod entries.This works correctly, when all keys used by the module were converted overto a module chain before the failure. If not then static_call_del_module()causes a #GP as it blindly assumes that key::mods points to a valid structstatic_call_mod.The problem is that key::mods is not a individual struct member of structstatic_call_key, it s part of a union to save space:        union {                /* bit 0: 0 = mods, 1 = sites */                unsigned long type;                struct static_call_mod *mods;                struct static_call_site *sites; };key::sites is a pointer to the list of built-in usage sites of the staticcall. The type of the pointer is differentiated by bit 0. A mods pointerhas the bit clear, the sites pointer has the bit set.As static_call_del_module() blidly assumes that the pointer is a validstatic_call_mod type, it fails to check for this failure case anddereferences the pointer to the list of built-in call sites, which isobviously bogus.Cure it by checking whether the key has a sites or a mods pointer.If it s a sites pointer then the key is not to be touched. As the sites arewalked in the same order as in __static_call_init() the site walk can beterminated because all subsequent sites have not been touched by the initcode due to the error exit.If it was converted before the allocation fail, then the inner loop whichsearches for a module match will find nothing.A fail in the second allocation in __static_call_init() is harmless anddoes not require special treatment. The first allocation succeeded andconverted the key to a module chain. That first entry has mod::mod == NULLand mod::next == NULL, so the inner loop of static_call_del_module() willneither find a module match nor a module chain. The next site in the walkwas either already converted, but can t match the module, or it will exitthe outer loop because it has a static_call_site pointer and not astatic_call_mod pointer.(CVE-2024-50002)\n\nIn the Linux kernel, the following vulnerability has been resolved:mac802154: Fix potential RCU dereference issue in mac802154_scan_workerIn the `mac802154_scan_worker` function, the `scan_req-\u0026gt;type` field wasaccessed after the RCU read-side critical section was unlocked. Accordingto RCU usage rules, this is illegal and can lead to unpredictablebehavior, such as accessing memory that has been updated or causinguse-after-free issues.This possible bug was identified using a static analysis tool developedby myself, specifically designed to detect RCU-related issues.To address this, the `scan_req-\u0026gt;type` value is now stored in a localvariable `scan_req_type` while still within the RCU read-side criticalsection. The `scan_req_type` is then used after the RCU lock is released,ensuring that the type value is safely accessed without violating RCUrules.(CVE-2024-50005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix null-ptr-deref in block_touch_buffer tracepoint\n\nPatch series \u0026quot;nilfs2: fix null-ptr-deref bugs on block tracepoints\u0026quot;.\n\nThis series fixes null pointer dereference bugs that occur when using\nnilfs2 and two block-related tracepoints.\n\n\nThis patch (of 2):\n\nIt has been reported that when using \u0026quot;block:block_touch_buffer\u0026quot;\ntracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a\nNULL pointer dereference, or a general protection fault when KASAN is\nenabled.\n\nThis happens because since the tracepoint was added in touch_buffer(), it\nreferences the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the\nbuffer head has a pointer to a block_device structure.  In the current\nimplementation, the block_device structure is set after the function\nreturns to the caller.\n\nHere, touch_buffer() is used to mark the folio/page that owns the buffer\nhead as accessed, but the common search helper for folio/page used by the\ncaller function was optimized to mark the folio/page as accessed when it\nwas reimplemented a long time ago, eliminating the need to call\ntouch_buffer() here in the first place.\n\nSo this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm: adv7511: Fix use-after-free in adv7533_attach_dsi()The host_node pointer was assigned and freed in adv7533_parse_dt(), andlater, adv7533_attach_dsi() uses the same. Fix this use-after-free issueby dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()in error path of probe() and also in the remove().(CVE-2024-57887)\n\nIn the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce ( ila: call nf_unregister_net_hooks() sooner )attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: \u0026lt;IRQ\u0026gt;  __dump_stack lib/dump_stack.c:94 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:378 [inline]  print_report+0xc3/0x620 mm/kasan/report.c:489  kasan_report+0xd9/0x110 mm/kasan/report.c:602  rht_key_hashfn include/linux/rhashtable.h:159 [inline]  __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604  rhashtable_lookup include/linux/rhashtable.h:646 [inline]  rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline]  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]  ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]  nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626  nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269  NF_HOOK include/linux/netfilter.h:312 [inline]  ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309  __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672  __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785  process_backlog+0x443/0x15f0 net/core/dev.c:6117  __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883  napi_poll net/core/dev.c:6952 [inline]  net_rx_action+0xa94/0x1010 net/core/dev.c:7074  handle_softirqs+0x213/0x8f0 kernel/softirq.c:561  __do_softirq kernel/softirq.c:595 [inline]  invoke_softirq kernel/softirq.c:435 [inline]  __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662  irq_exit_rcu+0x9/0x30 kernel/softirq.c:678  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]  sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049(CVE-2024-57900)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add check read-only before txBeginAnon() call\n\nAdded a read-only check before calling `txBeginAnon` in `extAlloc`\nand `extRecord`. This prevents modification attempts on a read-only\nmounted filesystem, avoiding potential errors or crashes.\n\nCall trace:\n txBeginAnon+0xac/0x154\n extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78\n jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248\n __block_write_begin_int+0x580/0x166c fs/buffer.c:2128\n __block_write_begin fs/buffer.c:2177 [inline]\n block_write_begin+0x98/0x11c fs/buffer.c:2236\n jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb2_lock\n\nIf smb_lock-\u0026gt;zero_len has value, -\u0026gt;llist of smb_lock is not delete and\nflock is old one. It will cause use-after-free on error handling\nroutine.(CVE-2025-21945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix slab-use-after-free on hdcp_work\n\n[Why]\nA slab-use-after-free is reported when HDCP is destroyed but the\nproperty_validate_dwork queue is still running.\n\n[How]\nCancel the delayed work when destroying workqueue.\n\n(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)(CVE-2025-21968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Apply the link chain quirk on NEC isoc endpoints\n\nTwo clearly different specimens of NEC uPD720200 (one with start/stop\nbug, one without) were seen to cause IOMMU faults after some Missed\nService Errors. Faulting address is immediately after a transfer ring\nsegment and patched dynamic debug messages revealed that the MSE was\nreceived when waiting for a TD near the end of that segment:\n\n[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0\n[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]\n[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]\n\nIt gets even funnier if the next page is a ring segment accessible to\nthe HC. Below, it reports MSE in segment at ff1e8000, plows through a\nzero-filled page at ff1e9000 and starts reporting events for TRBs in\npage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.\n\n[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.\n[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n\nAt some point completion events change from Isoch Buffer Overrun to\nShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.\n\n[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2\n\nIt\u0026apos;s possible that data from the isochronous device were written to\nrandom buffers of pending TDs on other endpoints (either IN or OUT),\nother devices or even other HCs in the same IOMMU domain.\n\nLastly, an error from a different USB device on another HC. Was it\ncaused by the above? I don\u0026apos;t know, but it may have been. The disk\nwas working without any other issues and generated PCIe traffic to\nstarve the NEC of upstream BW and trigger those MSEs. The two HCs\nshared one x1 slot by means of a commercial \u0026quot;PCIe splitter\u0026quot; board.\n\n[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd\n[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s\n[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00\n[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0\n\nFortunately, it appears that this ridiculous bug is avoided by setting\nthe chain bit of Link TRBs on isochronous rings. Other ancient HCs are\nknown which also expect the bit to be set and they ignore Link TRBs if\nit\u0026apos;s not. Reportedly, 0.95 spec guaranteed that the bit is set.\n\nThe bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports\ntens of MSEs per second and runs into the bug within seconds. Chaining\nLink TRBs allows the same workload to run for many minutes, many times.\n\nNo ne\n---truncated---(CVE-2025-22022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: put dl_stid if fail to queue dl_recall\n\nBefore calling nfsd4_run_cb to queue dl_recall to the callback_wq, we\nincrement the reference count of dl_stid.\nWe expect that after the corresponding work_struct is processed, the\nreference count of dl_stid will be decremented through the callback\nfunction nfsd4_cb_recall_release.\nHowever, if the call to nfsd4_run_cb fails, the incremented reference\ncount of dl_stid will not be decremented correspondingly, leading to the\nfollowing nfs4_stid leak:\nunreferenced object 0xffff88812067b578 (size 344):\n  comm \u0026quot;nfsd\u0026quot;, pid 2761, jiffies 4295044002 (age 5541.241s)\n  hex dump (first 32 bytes):\n    01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff  ....kkkk........\n    00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de  .kkkkkkk.....N..\n  backtrace:\n    kmem_cache_alloc+0x4b9/0x700\n    nfsd4_process_open1+0x34/0x300\n    nfsd4_open+0x2d1/0x9d0\n    nfsd4_proc_compound+0x7a2/0xe30\n    nfsd_dispatch+0x241/0x3e0\n    svc_process_common+0x5d3/0xcc0\n    svc_process+0x2a3/0x320\n    nfsd+0x180/0x2e0\n    kthread+0x199/0x1d0\n    ret_from_fork+0x30/0x50\n    ret_from_fork_asm+0x1b/0x30\nunreferenced object 0xffff8881499f4d28 (size 368):\n  comm \u0026quot;nfsd\u0026quot;, pid 2761, jiffies 4295044005 (age 5541.239s)\n  hex dump (first 32 bytes):\n    01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff  ........0M.I....\n    30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00  0M.I.... .......\n  backtrace:\n    kmem_cache_alloc+0x4b9/0x700\n    nfs4_alloc_stid+0x29/0x210\n    alloc_init_deleg+0x92/0x2e0\n    nfs4_set_delegation+0x284/0xc00\n    nfs4_open_delegation+0x216/0x3f0\n    nfsd4_process_open2+0x2b3/0xee0\n    nfsd4_open+0x770/0x9d0\n    nfsd4_proc_compound+0x7a2/0xe30\n    nfsd_dispatch+0x241/0x3e0\n    svc_process_common+0x5d3/0xcc0\n    svc_process+0x2a3/0x320\n    nfsd+0x180/0x2e0\n    kthread+0x199/0x1d0\n    ret_from_fork+0x30/0x50\n    ret_from_fork_asm+0x1b/0x30\nFix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if\nfail to queue dl_recall.(CVE-2025-22025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: don\u0026apos;t ignore the return code of svc_proc_register()\n\nCurrently, nfsd_proc_stat_init() ignores the return value of\nsvc_proc_register(). If the procfile creation fails, then the kernel\nwill WARN when it tries to remove the entry later.\n\nFix nfsd_proc_stat_init() to return the same type of pointer as\nsvc_proc_register(), and fix up nfsd_net_init() to check that and fail\nthe nfsd_net construction if it occurs.\n\nsvc_proc_register() can fail if the dentry can\u0026apos;t be allocated, or if an\nidentical dentry already exists. The second case is pretty unlikely in\nthe nfsd_net construction codepath, so if this happens, return -ENOMEM.(CVE-2025-22026)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix overflow in dacloffset bounds check\n\nThe dacloffset field was originally typed as int and used in an\nunchecked addition, which could overflow and bypass the existing\nbounds check in both smb_check_perm_dacl() and smb_inherit_dacl().\n\nThis could result in out-of-bounds memory access and a kernel crash\nwhen dereferencing the DACL pointer.\n\nThis patch converts dacloffset to unsigned int and uses\ncheck_add_overflow() to validate access to the DACL.(CVE-2025-22039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: add bounds check for create lease context\n\nAdd missing bounds check for create lease context.(CVE-2025-22042)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: add bounds check for durable handle context\n\nAdd missing bounds check for durable handle context.(CVE-2025-22043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: update channel list in reg notifier instead reg worker\n\nCurrently when ath11k gets a new channel list, it will be processed\naccording to the following steps:\n1. update new channel list to cfg80211 and queue reg_work.\n2. cfg80211 handles new channel list during reg_work.\n3. update cfg80211\u0026apos;s handled channel list to firmware by\nath11k_reg_update_chan_list().\n\nBut ath11k will immediately execute step 3 after reg_work is just\nqueued. Since step 2 is asynchronous, cfg80211 may not have completed\nhandling the new channel list, which may leading to an out-of-bounds\nwrite error:\nBUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list\nCall Trace:\n    ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]\n    kfree+0x109/0x3a0\n    ath11k_regd_update+0x1cf/0x350 [ath11k]\n    ath11k_regd_update_work+0x14/0x20 [ath11k]\n    process_one_work+0xe35/0x14c0\n\nShould ensure step 2 is completely done before executing step 3. Thus\nWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,\ncfg80211 will notify ath11k after step 2 is done.\n\nSo enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will\nnotify ath11k after step 2 is done. At this time, there will be no\nKASAN bug during the execution of the step 3.\n\n[1] https://patchwork.kernel.org/project/linux-wireless/patch/(CVE-2025-23133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: uprobes: Add missing fence.i after building the XOL buffer\n\nThe XOL (execute out-of-line) buffer is used to single-step the\nreplaced instruction(s) for uprobes. The RISC-V port was missing a\nproper fence.i (i$ flushing) after constructing the XOL buffer, which\ncan result in incorrect execution of stale/broken instructions.\n\nThis was found running the BPF selftests \u0026quot;test_progs:\nuprobe_autoattach, attach_probe\u0026quot; on the Spacemit K1/X60, where the\nuprobes tests randomly blew up.(CVE-2025-37822)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue\n\nWhen the task management thread processes reply queues while the reset\nthread resets them, the task management thread accesses an invalid queue ID\n(0xFFFF), set by the reset thread, which points to unallocated memory,\ncausing a crash.\n\nAdd flag \u0026apos;io_admin_reset_sync\u0026apos; to synchronize access between the reset,\nI/O, and admin threads. Before a reset, the reset handler sets this flag to\nblock I/O and admin processing threads. If any thread bypasses the initial\ncheck, the reset thread waits up to 10 seconds for processing to finish. If\nthe wait exceeds 10 seconds, the controller is marked as unrecoverable.(CVE-2025-37861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in session logoff\n\nThe sess-\u0026gt;user object can currently be in use by another thread, for\nexample if another connection has sent a session setup request to\nbind to the session being free\u0026apos;d. The handler for that connection could\nbe in the smb2_sess_setup function which makes use of sess-\u0026gt;user.(CVE-2025-37899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation\n\nCurrently during the multi-link element defragmentation process, the\nmulti-link element length added to the total IEs length when calculating\nthe length of remaining IEs after the multi-link element in\ncfg80211_defrag_mle(). This could lead to out-of-bounds access if the\nmulti-link element or its corresponding fragment elements are the last\nelements in the IEs buffer.\n\nTo address this issue, correctly calculate the remaining IEs length by\ndeducting the multi-link element end offset from total IEs end offset.(CVE-2025-37973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: displayport: Fix NULL pointer access\n\nThis patch ensures that the UCSI driver waits for all pending tasks in the\nucsi_displayport_work workqueue to finish executing before proceeding with\nthe partner removal.(CVE-2025-37994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: fix region locking in hash types\n\nRegion locking introduced in v5.6-rc4 contained three macros to handle\nthe region locks: ahash_bucket_start(), ahash_bucket_end() which gave\nback the start and end hash bucket values belonging to a given region\nlock and ahash_region() which should give back the region lock belonging\nto a given hash bucket. The latter was incorrect which can lead to a\nrace condition between the garbage collector and adding new elements\nwhen a hash type of set is defined with timeouts.(CVE-2025-37997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma: Add missing locking\n\nRecent kernels complain about a missing lock in k3-udma.c when the lock\nvalidator is enabled:\n\n[    4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238\n[    4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28\n[    4.144867] Hardware name: pp-v12 (DT)\n[    4.148648] Workqueue: events udma_check_tx_completion\n[    4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    4.160834] pc : udma_start.isra.0+0x34/0x238\n[    4.165227] lr : udma_start.isra.0+0x30/0x238\n[    4.169618] sp : ffffffc083cabcf0\n[    4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005\n[    4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000\n[    4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670\n[    4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030\n[    4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048\n[    4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001\n[    4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68\n[    4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8\n[    4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000\n[    4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000\n[    4.244986] Call trace:\n[    4.247463]  udma_start.isra.0+0x34/0x238\n[    4.251509]  udma_check_tx_completion+0xd0/0xdc\n[    4.256076]  process_one_work+0x244/0x3fc\n[    4.260129]  process_scheduled_works+0x6c/0x74\n[    4.264610]  worker_thread+0x150/0x1dc\n[    4.268398]  kthread+0xd8/0xe8\n[    4.271492]  ret_from_fork+0x10/0x20\n[    4.275107] irq event stamp: 220\n[    4.278363] hardirqs last  enabled at (219): [\u0026lt;ffffffc080a27c7c\u0026gt;] _raw_spin_unlock_irq+0x38/0x50\n[    4.287183] hardirqs last disabled at (220): [\u0026lt;ffffffc080a1c154\u0026gt;] el1_dbg+0x24/0x50\n[    4.294879] softirqs last  enabled at (182): [\u0026lt;ffffffc080037e68\u0026gt;] handle_softirqs+0x1c0/0x3cc\n[    4.303437] softirqs last disabled at (177): [\u0026lt;ffffffc080010170\u0026gt;] __do_softirq+0x1c/0x28\n[    4.311559] ---[ end trace 0000000000000000 ]---\n\nThis commit adds the missing locking.(CVE-2025-38005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock\n\n... or we risk stealing final mntput from sync umount - raising mnt_count\nafter umount(2) has verified that victim is not busy, but before it\nhas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn\u0026apos;t see\nthat it\u0026apos;s safe to quietly undo mnt_count increment and leaves dropping\nthe reference to caller, where it\u0026apos;ll be a full-blown mntput().\n\nCheck under mount_lock is needed; leaving the current one done before\ntaking that makes no sense - it\u0026apos;s nowhere near common enough to bother\nwith.(CVE-2025-38058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Check return value from memblock_phys_alloc_range()\n\nAt least with CONFIG_PHYSICAL_START=0x100000, if there is \u0026lt; 4 MiB of\ncontiguous free memory available at this point, the kernel will crash\nand burn because memblock_phys_alloc_range() returns 0 on failure,\nwhich leads memblock_phys_free() to throw the first 4 MiB of physical\nmemory to the wolves.\n\nAt a minimum it should fail gracefully with a meaningful diagnostic,\nbut in fact everything seems to work fine without the weird reserve\nallocation.(CVE-2025-38071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix ECVF vports unload on shutdown flow\n\nFix shutdown flow UAF when a virtual function is created on the embedded\nchip (ECVF) of a BlueField device. In such case the vport acl ingress\ntable is not properly destroyed.\n\nECVF functionality is independent of ecpf_vport_exists capability and\nthus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not\ntest it when enabling/disabling ECVF vports.\n\nkernel log:\n[] refcount_t: underflow; use-after-free.\n[] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28\n   refcount_warn_saturate+0x124/0x220\n----------------\n[] Call trace:\n[] refcount_warn_saturate+0x124/0x220\n[] tree_put_node+0x164/0x1e0 [mlx5_core]\n[] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core]\n[] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core]\n[] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core]\n[] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core]\n[] esw_vport_cleanup+0x64/0x90 [mlx5_core]\n[] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core]\n[] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core]\n[] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core]\n[] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core]\n[] mlx5_sriov_detach+0x40/0x50 [mlx5_core]\n[] mlx5_unload+0x40/0xc4 [mlx5_core]\n[] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core]\n[] mlx5_unload_one+0x3c/0x60 [mlx5_core]\n[] shutdown+0x7c/0xa4 [mlx5_core]\n[] pci_device_shutdown+0x3c/0xa0\n[] device_shutdown+0x170/0x340\n[] __do_sys_reboot+0x1f4/0x2a0\n[] __arm64_sys_reboot+0x2c/0x40\n[] invoke_syscall+0x78/0x100\n[] el0_svc_common.constprop.0+0x54/0x184\n[] do_el0_svc+0x30/0xac\n[] el0_svc+0x48/0x160\n[] el0t_64_sync_handler+0xa4/0x12c\n[] el0t_64_sync+0x1a4/0x1a8\n[] --[ end trace 9c4601d68c70030e ]---(CVE-2025-38109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: Initialize ssc before laundromat_work to prevent NULL dereference\n\nIn nfs4_state_start_net(), laundromat_work may access nfsd_ssc through\nnfs4_laundromat -\u0026gt; nfsd4_ssc_expire_umount. If nfsd_ssc isn\u0026apos;t initialized,\nthis can cause NULL pointer dereference.\n\nNormally the delayed start of laundromat_work allows sufficient time for\nnfsd_ssc initialization to complete. However, when the kernel waits too\nlong for userspace responses (e.g. in nfs4_state_start_net -\u0026gt;\nnfsd4_end_grace -\u0026gt; nfsd4_record_grace_done -\u0026gt; nfsd4_cld_grace_done -\u0026gt;\ncld_pipe_upcall -\u0026gt; __cld_pipe_upcall -\u0026gt; wait_for_completion path), the\ndelayed work may start before nfsd_ssc initialization finishes.\n\nFix this by moving nfsd_ssc initialization before starting laundromat_work.(CVE-2025-38231)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkernfs: Relax constraint in draining guard\n\nThe active reference lifecycle provides the break/unbreak mechanism but\nthe active reference is not truly active after unbreak -- callers don\u0026apos;t\nuse it afterwards but it\u0026apos;s important for proper pairing of kn-\u0026gt;active\ncounting. Assuming this mechanism is in place, the WARN check in\nkernfs_should_drain_open_files() is too sensitive -- it may transiently\ncatch those (rightful) callers between\nkernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen\nRidong:\n\n\tkernfs_remove_by_name_ns\tkernfs_get_active // active=1\n\t__kernfs_remove\t\t\t\t\t  // active=0x80000002\n\tkernfs_drain\t\t\t...\n\twait_event\n\t//waiting (active == 0x80000001)\n\t\t\t\t\tkernfs_break_active_protection\n\t\t\t\t\t// active = 0x80000001\n\t// continue\n\t\t\t\t\tkernfs_unbreak_active_protection\n\t\t\t\t\t// active = 0x80000002\n\t...\n\tkernfs_should_drain_open_files\n\t// warning occurs\n\t\t\t\t\tkernfs_put_active\n\nTo avoid the false positives (mind panic_on_warn) remove the check altogether.\n(This is meant as quick fix, I think active reference break/unbreak may be\nsimplified with larger rework.)(CVE-2025-38282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes\u0026apos; dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent\u0026apos;s parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n    tc qdisc add dev lo root handle 1: drr\n    tc filter add dev lo parent 1: basic classid 1:1\n    tc class add dev lo parent 1: classid 1:1 drr\n    tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n    tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n    tc qdisc add dev lo parent 2:1 handle 3: netem\n    tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n    echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n    tc class delete dev lo classid 1:1\n    echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Check dce_hwseq before dereferencing it\n\n[WHAT]\n\nhws was checked for null earlier in dce110_blank_stream, indicating hws\ncan be null, and should be checked whenever it is used.\n\n(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)(CVE-2025-38361)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: fix uaf in nbd_genl_connect() error path\n\nThere is a use-after-free issue in nbd:\n\nblock nbd6: Receive control failed (result -104)\nblock nbd6: shutting down sockets\n==================================================================\nBUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022\nWrite of size 4 at addr ffff8880295de478 by task kworker/u33:0/67\n\nCPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nWorkqueue: nbd6-recv recv_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n instrument_atomic_read_write include/linux/instrumented.h:96 [inline]\n atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline]\n recv_work+0x694/0xa80 drivers/block/nbd.c:1022\n process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238\n process_scheduled_works kernel/workqueue.c:3319 [inline]\n worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n kthread+0x3c2/0x780 kernel/kthread.c:464\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u0026lt;/TASK\u0026gt;\n\nnbd_genl_connect() does not properly stop the device on certain\nerror paths after nbd_start_device() has been called. This causes\nthe error path to put nbd-\u0026gt;config while recv_work continue to use\nthe config after putting it, leading to use-after-free in recv_work.\n\nThis patch moves nbd_start_device() after the backend file creation.(CVE-2025-38443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Abort __tc_modify_qdisc if parent class does not exist\n\nLion\u0026apos;s patch [1] revealed an ancient bug in the qdisc API.\nWhenever a user creates/modifies a qdisc specifying as a parent another\nqdisc, the qdisc API will, during grafting, detect that the user is\nnot trying to attach to a class and reject. However grafting is\nperformed after qdisc_create (and thus the qdiscs\u0026apos; init callback) is\nexecuted. In qdiscs that eventually call qdisc_tree_reduce_backlog\nduring init or change (such as fq, hhf, choke, etc), an issue\narises. For example, executing the following commands:\n\nsudo tc qdisc add dev lo root handle a: htb default 2\nsudo tc qdisc add dev lo parent a: handle beef fq\n\nQdiscs such as fq, hhf, choke, etc unconditionally invoke\nqdisc_tree_reduce_backlog() in their control path init() or change() which\nthen causes a failure to find the child class; however, that does not stop\nthe unconditional invocation of the assumed child qdisc\u0026apos;s qlen_notify with\na null class. All these qdiscs make the assumption that class is non-null.\n\nThe solution is ensure that qdisc_leaf() which looks up the parent\nclass, and is invoked prior to qdisc_create(), should return failure on\nnot finding the class.\nIn this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the\nparentid doesn\u0026apos;t correspond to a class, so that we can detect it\nearlier on and abort before qdisc_create is called.\n\n[1] https://lore.kernel.org/netdev/(CVE-2025-38457)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime\n\nAssuming the \u0026quot;rx-vlan-filter\u0026quot; feature is enabled on a net device, the\n8021q module will automatically add or remove VLAN 0 when the net device\nis put administratively up or down, respectively. There are a couple of\nproblems with the above scheme.\n\nThe first problem is a memory leak that can happen if the \u0026quot;rx-vlan-filter\u0026quot;\nfeature is disabled while the device is running:\n\n # ip link add bond1 up type bond mode 0\n # ethtool -K bond1 rx-vlan-filter off\n # ip link del dev bond1\n\nWhen the device is put administratively down the \u0026quot;rx-vlan-filter\u0026quot;\nfeature is disabled, so the 8021q module will not remove VLAN 0 and the\nmemory will be leaked [1].\n\nAnother problem that can happen is that the kernel can automatically\ndelete VLAN 0 when the device is put administratively down despite not\nadding it when the device was put administratively up since during that\ntime the \u0026quot;rx-vlan-filter\u0026quot; feature was disabled. null-ptr-unref or\nbug_on[2] will be triggered by unregister_vlan_dev() for refcount\nimbalance if toggling filtering during runtime:\n\n$ ip link add bond0 type bond mode 0\n$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q\n$ ethtool -K bond0 rx-vlan-filter off\n$ ifconfig bond0 up\n$ ethtool -K bond0 rx-vlan-filter on\n$ ifconfig bond0 down\n$ ip link del vlan0\n\nRoot cause is as below:\nstep1: add vlan0 for real_dev, such as bond, team.\nregister_vlan_dev\n    vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1\nstep2: disable vlan filter feature and enable real_dev\nstep3: change filter from 0 to 1\nvlan_device_event\n    vlan_filter_push_vids\n        ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0\nstep4: real_dev down\nvlan_device_event\n    vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0\n        vlan_info_rcu_free //free vlan0\nstep5: delete vlan0\nunregister_vlan_dev\n    BUG_ON(!vlan_info); //vlan_info is null\n\nFix both problems by noting in the VLAN info whether VLAN 0 was\nautomatically added upon NETDEV_UP and based on that decide whether it\nshould be deleted upon NETDEV_DOWN, regardless of the state of the\n\u0026quot;rx-vlan-filter\u0026quot; feature.\n\n[1]\nunreferenced object 0xffff8880068e3100 (size 256):\n  comm \u0026quot;ip\u0026quot;, pid 384, jiffies 4296130254\n  hex dump (first 32 bytes):\n    00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00  . 0.............\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace (crc 81ce31fa):\n    __kmalloc_cache_noprof+0x2b5/0x340\n    vlan_vid_add+0x434/0x940\n    vlan_device_event.cold+0x75/0xa8\n    notifier_call_chain+0xca/0x150\n    __dev_notify_flags+0xe3/0x250\n    rtnl_configure_link+0x193/0x260\n    rtnl_newlink_create+0x383/0x8e0\n    __rtnl_newlink+0x22c/0xa40\n    rtnl_newlink+0x627/0xb00\n    rtnetlink_rcv_msg+0x6fb/0xb70\n    netlink_rcv_skb+0x11f/0x350\n    netlink_unicast+0x426/0x710\n    netlink_sendmsg+0x75a/0xc20\n    __sock_sendmsg+0xc1/0x150\n    ____sys_sendmsg+0x5aa/0x7b0\n    ___sys_sendmsg+0xfc/0x180\n\n[2]\nkernel BUG at net/8021q/vlan.c:99!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))\nRSP: 0018:ffff88810badf310 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8\nRBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80\nR10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000\nR13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e\nFS:  00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\n---truncated---(CVE-2025-38470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix race condition on qfq_aggregate\n\nA race condition can occur when \u0026apos;agg\u0026apos; is modified in qfq_change_agg\n(called during qfq_enqueue) while other threads access it\nconcurrently. For example, qfq_dump_class may trigger a NULL\ndereference, and qfq_delete_class may cause a use-after-free.\n\nThis patch addresses the issue by:\n\n1. Moved qfq_destroy_class into the critical section.\n\n2. Added sch_tree_lock protection to qfq_dump_class and\nqfq_dump_class_stats.(CVE-2025-38477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in cifs_oplock_break\n\nA race condition can occur in cifs_oplock_break() leading to a\nuse-after-free of the cinode structure when unmounting:\n\n  cifs_oplock_break()\n    _cifsFileInfo_put(cfile)\n      cifsFileInfo_put_final()\n        cifs_sb_deactive()\n          [last ref, start releasing sb]\n            kill_sb()\n              kill_anon_super()\n                generic_shutdown_super()\n                  evict_inodes()\n                    dispose_list()\n                      evict()\n                        destroy_inode()\n                          call_rcu(\u0026amp;inode-\u0026gt;i_rcu, i_callback)\n    spin_lock(\u0026amp;cinode-\u0026gt;open_file_lock)  \u0026lt;- OK\n                            [later] i_callback()\n                              cifs_free_inode()\n                                kmem_cache_free(cinode)\n    spin_unlock(\u0026amp;cinode-\u0026gt;open_file_lock)  \u0026lt;- UAF\n    cifs_done_oplock_break(cinode)       \u0026lt;- UAF\n\nThe issue occurs when umount has already released its reference to the\nsuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this\nreleases the last reference, triggering the immediate cleanup of all\ninodes under RCU. However, cifs_oplock_break() continues to access the\ncinode after this point, resulting in use-after-free.\n\nFix this by holding an extra reference to the superblock during the\nentire oplock break operation. This ensures that the superblock and\nits inodes remain valid until the oplock break completes.(CVE-2025-38527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: fix handling of server side tls alerts\n\nScott Mayhew discovered a security exploit in NFS over TLS in\ntls_alert_recv() due to its assumption it can read data from\nthe msg iterator\u0026apos;s kvec..\n\nkTLS implementation splits TLS non-data record payload between\nthe control message buffer (which includes the type such as TLS\naler or TLS cipher change) and the rest of the payload (say TLS\nalert\u0026apos;s level/description) which goes into the msg payload buffer.\n\nThis patch proposes to rework how control messages are setup and\nused by sock_recvmsg().\n\nIf no control message structure is setup, kTLS layer will read and\nprocess TLS data record types. As soon as it encounters a TLS control\nmessage, it would return an error. At that point, NFS can setup a\nkvec backed msg buffer and read in the control message such as a\nTLS alert. Msg iterator can advance the kvec pointer as a part of\nthe copy process thus we need to revert the iterator before calling\ninto the tls_alert_recv.(CVE-2025-38566)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent infinite loop in rt6_nlmsg_size()\n\nWhile testing prior patch, I was able to trigger\nan infinite loop in rt6_nlmsg_size() in the following place:\n\nlist_for_each_entry_rcu(sibling, \u0026amp;f6i-\u0026gt;fib6_siblings,\n\t\t\tfib6_siblings) {\n\trt6_nh_nlmsg_size(sibling-\u0026gt;fib6_nh, \u0026amp;nexthop_len);\n}\n\nThis is because fib6_del_route() and fib6_add_rt2node()\nuses list_del_rcu(), which can confuse rcu readers,\nbecause they might no longer see the head of the list.\n\nRestart the loop if f6i-\u0026gt;fib6_nsiblings is zero.(CVE-2025-38588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: Fix semi-unbounded recursion\n\nEnsure that epoll instances can never form a graph deeper than\nEP_MAX_NESTS+1 links.\n\nCurrently, ep_loop_check_proc() ensures that the graph is loop-free and\ndoes some recursion depth checks, but those recursion depth checks don\u0026apos;t\nlimit the depth of the resulting tree for two reasons:\n\n - They don\u0026apos;t look upwards in the tree.\n - If there are multiple downwards paths of different lengths, only one of\n   the paths is actually considered for the depth check since commit\n   28d82dc1c4ed (\u0026quot;epoll: limit paths\u0026quot;).\n\nEssentially, the current recursion depth check in ep_loop_check_proc() just\nserves to prevent it from recursing too deeply while checking for loops.\n\nA more thorough check is done in reverse_path_check() after the new graph\nedge has already been created; this checks, among other things, that no\npaths going upwards from any non-epoll file with a length of more than 5\nedges exist. However, this check does not apply to non-epoll files.\n\nAs a result, it is possible to recurse to a depth of at least roughly 500,\ntested on v6.15. (I am unsure if deeper recursion is possible; and this may\nhave changed with commit 8c44dac8add7 (\u0026quot;eventpoll: Fix priority inversion\nproblem\u0026quot;).)\n\nTo fix it:\n\n1. In ep_loop_check_proc(), note the subtree depth of each visited node,\nand use subtree depths for the total depth calculation even when a subtree\nhas already been visited.\n2. Add ep_get_upwards_depth_proc() for similarly determining the maximum\ndepth of an upwards walk.\n3. In ep_loop_check(), use these values to limit the total path length\nbetween epoll nodes to EP_MAX_NESTS edges.(CVE-2025-38614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrv: Use strings in da monitors tracepoints\n\nUsing DA monitors tracepoints with KASAN enabled triggers the following\nwarning:\n\n BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0\n Read of size 32 at addr ffffffffaada8980 by task ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n [...]\n  do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0\n  ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10\n  ? trace_event_sncid+0x83/0x200\n  trace_event_sncid+0x163/0x200\n [...]\n The buggy address belongs to the variable:\n  automaton_snep+0x4e0/0x5e0\n\nThis is caused by the tracepoints reading 32 bytes __array instead of\n__string from the automata definition. Such strings are literals and\nreading 32 bytes ends up in out of bound memory accesses (e.g. the next\nautomaton\u0026apos;s data in this case).\nThe error is harmless as, while printing the string, we stop at the null\nterminator, but it should still be fixed.\n\nUse the __string facilities while defining the tracepoints to avoid\nreading out of bound memory.(CVE-2025-38636)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix a null pointer dereference in ice_copy_and_init_pkg()\n\nAdd check for the return value of devm_kmemdup()\nto prevent potential null pointer dereference.(CVE-2025-38664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()\n\nsnd_soc_remove_pcm_runtime() might be called with rtd == NULL which will\nleads to null pointer dereference.\nThis was reproduced with topology loading and marking a link as ignore\ndue to missing hardware component on the system.\nOn module removal the soc_tplg_remove_link() would call\nsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,\nno runtime was created.(CVE-2025-38706)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: avoid infinite retry looping in netlink_unicast()\n\nnetlink_attachskb() checks for the socket\u0026apos;s read memory allocation\nconstraints. Firstly, it has:\n\n  rmem \u0026lt; READ_ONCE(sk-\u0026gt;sk_rcvbuf)\n\nto check if the just increased rmem value fits into the socket\u0026apos;s receive\nbuffer. If not, it proceeds and tries to wait for the memory under:\n\n  rmem + skb-\u0026gt;truesize \u0026gt; READ_ONCE(sk-\u0026gt;sk_rcvbuf)\n\nThe checks don\u0026apos;t cover the case when skb-\u0026gt;truesize + sk-\u0026gt;sk_rmem_alloc is\nequal to sk-\u0026gt;sk_rcvbuf. Thus the function neither successfully accepts\nthese conditions, nor manages to reschedule the task - and is called in\nretry loop for indefinite time which is caught as:\n\n  rcu: INFO: rcu_sched self-detected stall on CPU\n  rcu:     0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212\n  (t=26000 jiffies g=230833 q=259957)\n  NMI backtrace for cpu 0\n  CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014\n  Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  dump_stack lib/dump_stack.c:120\n  nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105\n  nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62\n  rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335\n  rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590\n  update_process_times kernel/time/timer.c:1953\n  tick_sched_handle kernel/time/tick-sched.c:227\n  tick_sched_timer kernel/time/tick-sched.c:1399\n  __hrtimer_run_queues kernel/time/hrtimer.c:1652\n  hrtimer_interrupt kernel/time/hrtimer.c:1717\n  __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113\n  asm_call_irq_on_stack arch/x86/entry/entry_64.S:808\n  \u0026lt;/IRQ\u0026gt;\n\n  netlink_attachskb net/netlink/af_netlink.c:1234\n  netlink_unicast net/netlink/af_netlink.c:1349\n  kauditd_send_queue kernel/audit.c:776\n  kauditd_thread kernel/audit.c:897\n  kthread kernel/kthread.c:328\n  ret_from_fork arch/x86/entry/entry_64.S:304\n\nRestore the original behavior of the check which commit in Fixes\naccidentally missed when restructuring the code.\n\nFound by Linux Verification Center (linuxtesting.org).(CVE-2025-38727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()\n\nThe function mod_hdcp_hdcp1_create_session() calls the function\nget_first_active_display(), but does not check its return value.\nThe return value is a null pointer if the display list is empty.\nThis will lead to a null pointer dereference.\n\nAdd a null pointer check for get_first_active_display() and return\nMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.\n\nThis is similar to the commit c3e9826a2202\n(\u0026quot;drm/amd/display: Add null pointer check for get_first_active_display()\u0026quot;).\n\n(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)(CVE-2025-39675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Fix backlog accounting in qdisc_dequeue_internal\n\nThis issue applies for the following qdiscs: hhf, fq, fq_codel, and\nfq_pie, and occurs in their change handlers when adjusting to the new\nlimit. The problem is the following in the values passed to the\nsubsequent qdisc_tree_reduce_backlog call given a tbf parent:\n\n   When the tbf parent runs out of tokens, skbs of these qdiscs will\n   be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,\n   which accounts for both qlen and backlog. However, in the case of\n   qdisc_dequeue_internal, ONLY qlen is accounted for when pulling\n   from gso_skb. This means that these qdiscs are missing a\n   qdisc_qstats_backlog_dec when dropping packets to satisfy the\n   new limit in their change handlers.\n\n   One can observe this issue with the following (with tc patched to\n   support a limit of 0):\n\n   export TARGET=fq\n   tc qdisc del dev lo root\n   tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms\n   tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000\n   echo \u0026apos;\u0026apos;; echo \u0026apos;add child\u0026apos;; tc -s -d qdisc show dev lo\n   ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2\u0026gt;\u0026amp;1 \u0026gt;/dev/null\n   echo \u0026apos;\u0026apos;; echo \u0026apos;after ping\u0026apos;; tc -s -d qdisc show dev lo\n   tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0\n   echo \u0026apos;\u0026apos;; echo \u0026apos;after limit drop\u0026apos;; tc -s -d qdisc show dev lo\n   tc qdisc replace dev lo handle 2: parent 1:1 sfq\n   echo \u0026apos;\u0026apos;; echo \u0026apos;post graft\u0026apos;; tc -s -d qdisc show dev lo\n\n   The second to last show command shows 0 packets but a positive\n   number (74) of backlog bytes. The problem becomes clearer in the\n   last show command, where qdisc_purge_queue triggers\n   qdisc_tree_reduce_backlog with the positive backlog and causes an\n   underflow in the tbf parent\u0026apos;s backlog (4096 Mb instead of 0).\n\nTo fix this issue, the codepath for all clients of qdisc_dequeue_internal\nhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.\nqdisc_dequeue_internal handles the backlog adjustments for all cases that\ndo not directly use the dequeue handler.\n\nThe old fq_codel_change limit adjustment loop accumulated the arguments to\nthe subsequent qdisc_tree_reduce_backlog call through the cstats field.\nHowever, this is confusing and error prone as fq_codel_dequeue could also\npotentially mutate this field (which qdisc_dequeue_internal calls in the\nnon gso_skb case), so we have unified the code here with other qdiscs.(CVE-2025-39677)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()\n\nsyzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`.  A kernel\nbuffer is allocated to hold `insn-\u0026gt;n` samples (each of which is an\n`unsigned int`).  For some instruction types, `insn-\u0026gt;n` samples are\ncopied back to user-space, unless an error code is being returned.  The\nproblem is that not all the instruction handlers that need to return\ndata to userspace fill in the whole `insn-\u0026gt;n` samples, so that there is\nan information leak.  There is a similar syzbot report for\n`do_insnlist_ioctl()`, although it does not have a reproducer for it at\nthe time of writing.\n\nOne culprit is `insn_rw_emulate_bits()` which is used as the handler for\n`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have\na specific handler for that instruction, but do have an `INSN_BITS`\nhandler.  For `INSN_READ` it only fills in at most 1 sample, so if\n`insn-\u0026gt;n` is greater than 1, the remaining `insn-\u0026gt;n - 1` samples copied\nto userspace will be uninitialized kernel data.\n\nAnother culprit is `vm80xx_ai_insn_read()` in the \u0026quot;vm80xx\u0026quot; driver.  It\nnever returns an error, even if it fails to fill the buffer.\n\nFix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure\nthat uninitialized parts of the allocated buffer are zeroed before\nhandling each instruction.\n\nThanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`.  That fix\nreplaced the call to `kmalloc_array()` with `kcalloc()`, but it is not\nalways necessary to clear the whole buffer.(CVE-2025-39684)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a race when updating an existing write\n\nAfter nfs_lock_and_join_requests() tests for whether the request is\nstill attached to the mapping, nothing prevents a call to\nnfs_inode_remove_request() from succeeding until we actually lock the\npage group.\nThe reason is that whoever called nfs_inode_remove_request() doesn\u0026apos;t\nnecessarily have a lock on the page group head.\n\nSo in order to avoid races, let\u0026apos;s take the page group lock earlier in\nnfs_lock_and_join_requests(), and hold it across the removal of the\nrequest in nfs_inode_remove_request().(CVE-2025-39697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix memory corruption when FW resources change during ifdown\n\nbnxt_set_dflt_rings() assumes that it is always called before any TC has\nbeen created.  So it doesn\u0026apos;t take bp-\u0026gt;num_tc into account and assumes\nthat it is always 0 or 1.\n\nIn the FW resource or capability change scenario, the FW will return\nflags in bnxt_hwrm_if_change() that will cause the driver to\nreinitialize and call bnxt_cancel_reservations().  This will lead to\nbnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp-\u0026gt;num_tc\nmay be greater than 1.  This will cause bp-\u0026gt;tx_ring[] to be sized too\nsmall and cause memory corruption in bnxt_alloc_cp_rings().\n\nFix it by properly scaling the TX rings by bp-\u0026gt;num_tc in the code\npaths mentioned above.  Add 2 helper functions to determine\nbp-\u0026gt;tx_nr_rings and bp-\u0026gt;tx_nr_rings_per_tc.(CVE-2025-39810)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: Fix slab-out-of-bounds in efivarfs_d_compare\n\nObserved on kernel 6.6 (present on master as well):\n\n  BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0\n  Call trace:\n   kasan_check_range+0xe8/0x190\n   __asan_loadN+0x1c/0x28\n   memcmp+0x98/0xd0\n   efivarfs_d_compare+0x68/0xd8\n   __d_lookup_rcu_op_compare+0x178/0x218\n   __d_lookup_rcu+0x1f8/0x228\n   d_alloc_parallel+0x150/0x648\n   lookup_open.isra.0+0x5f0/0x8d0\n   open_last_lookups+0x264/0x828\n   path_openat+0x130/0x3f8\n   do_filp_open+0x114/0x248\n   do_sys_openat2+0x340/0x3c0\n   __arm64_sys_openat+0x120/0x1a0\n\nIf dentry-\u0026gt;d_name.len \u0026lt; EFI_VARIABLE_GUID_LEN , \u0026apos;guid\u0026apos; can become\nnegative, leadings to oob. The issue can be triggered by parallel\nlookups using invalid filename:\n\n  T1\t\t\tT2\n  lookup_open\n   -\u0026gt;lookup\n    simple_lookup\n     d_add\n     // invalid dentry is added to hash list\n\n\t\t\tlookup_open\n\t\t\t d_alloc_parallel\n\t\t\t  __d_lookup_rcu\n\t\t\t   __d_lookup_rcu_op_compare\n\t\t\t    hlist_bl_for_each_entry_rcu\n\t\t\t    // invalid dentry can be retrieved\n\t\t\t     -\u0026gt;d_compare\n\t\t\t      efivarfs_d_compare\n\t\t\t      // oob\n\nFix it by checking \u0026apos;guid\u0026apos; before cmp.(CVE-2025-39817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix race with concurrent opens in rename(2)\n\nBesides sending the rename request to the server, the rename process\nalso involves closing any deferred close, waiting for outstanding I/O\nto complete as well as marking all existing open handles as deleted to\nprevent them from deferring closes, which increases the race window\nfor potential concurrent opens on the target file.\n\nFix this by unhashing the dentry in advance to prevent any concurrent\nopens on the target.(CVE-2025-39825)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: writeback: fix use-after-free in __mark_inode_dirty()\n\nAn use-after-free issue occurred when __mark_inode_dirty() get the\nbdi_writeback that was in the progress of switching.\n\nCPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1\n......\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __mark_inode_dirty+0x124/0x418\nlr : __mark_inode_dirty+0x118/0x418\nsp : ffffffc08c9dbbc0\n........\nCall trace:\n __mark_inode_dirty+0x124/0x418\n generic_update_time+0x4c/0x60\n file_modified+0xcc/0xd0\n ext4_buffered_write_iter+0x58/0x124\n ext4_file_write_iter+0x54/0x704\n vfs_write+0x1c0/0x308\n ksys_write+0x74/0x10c\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x114\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x40/0xe4\n el0t_64_sync_handler+0x120/0x12c\n el0t_64_sync+0x194/0x198\n\nRoot cause is:\n\nsystemd-random-seed                         kworker\n----------------------------------------------------------------------\n___mark_inode_dirty                     inode_switch_wbs_work_fn\n\n  spin_lock(\u0026amp;inode-\u0026gt;i_lock);\n  inode_attach_wb\n  locked_inode_to_wb_and_lock_list\n     get inode-\u0026gt;i_wb\n     spin_unlock(\u0026amp;inode-\u0026gt;i_lock);\n     spin_lock(\u0026amp;wb-\u0026gt;list_lock)\n  spin_lock(\u0026amp;inode-\u0026gt;i_lock)\n  inode_io_list_move_locked\n  spin_unlock(\u0026amp;wb-\u0026gt;list_lock)\n  spin_unlock(\u0026amp;inode-\u0026gt;i_lock)\n                                    spin_lock(\u0026amp;old_wb-\u0026gt;list_lock)\n                                      inode_do_switch_wbs\n                                        spin_lock(\u0026amp;inode-\u0026gt;i_lock)\n                                        inode-\u0026gt;i_wb = new_wb\n                                        spin_unlock(\u0026amp;inode-\u0026gt;i_lock)\n                                    spin_unlock(\u0026amp;old_wb-\u0026gt;list_lock)\n                                    wb_put_many(old_wb, nr_switched)\n                                      cgwb_release\n                                      old wb released\n  wb_wakeup_delayed() accesses wb,\n  then trigger the use-after-free\n  issue\n\nFix this race condition by holding inode spinlock until\nwb_wakeup_delayed() finished.(CVE-2025-39866)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkernfs: Fix UAF in polling when open file is released\n\nA use-after-free (UAF) vulnerability was identified in the PSI (Pressure\nStall Information) monitoring mechanism:\n\nBUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140\nRead of size 8 at addr ffff3de3d50bd308 by task systemd/1\n\npsi_trigger_poll+0x3c/0x140\ncgroup_pressure_poll+0x70/0xa0\ncgroup_file_poll+0x8c/0x100\nkernfs_fop_poll+0x11c/0x1c0\nep_item_poll.isra.0+0x188/0x2c0\n\nAllocated by task 1:\ncgroup_file_open+0x88/0x388\nkernfs_fop_open+0x73c/0xaf0\ndo_dentry_open+0x5fc/0x1200\nvfs_open+0xa0/0x3f0\ndo_open+0x7e8/0xd08\npath_openat+0x2fc/0x6b0\ndo_filp_open+0x174/0x368\n\nFreed by task 8462:\ncgroup_file_release+0x130/0x1f8\nkernfs_drain_open_files+0x17c/0x440\nkernfs_drain+0x2dc/0x360\nkernfs_show+0x1b8/0x288\ncgroup_file_show+0x150/0x268\ncgroup_pressure_write+0x1dc/0x340\ncgroup_file_write+0x274/0x548\n\nReproduction Steps:\n1. Open test/cpu.pressure and establish epoll monitoring\n2. Disable monitoring: echo 0 \u0026gt; test/cgroup.pressure\n3. Re-enable monitoring: echo 1 \u0026gt; test/cgroup.pressure\n\nThe race condition occurs because:\n1. When cgroup.pressure is disabled (echo 0 \u0026gt; cgroup.pressure), it:\n   - Releases PSI triggers via cgroup_file_release()\n   - Frees of-\u0026gt;priv through kernfs_drain_open_files()\n2. While epoll still holds reference to the file and continues polling\n3. Re-enabling (echo 1 \u0026gt; cgroup.pressure) accesses freed of-\u0026gt;priv\n\nepolling\t\t\tdisable/enable cgroup.pressure\nfd=open(cpu.pressure)\nwhile(1)\n...\nepoll_wait\nkernfs_fop_poll\nkernfs_get_active = true\techo 0 \u0026gt; cgroup.pressure\n...\t\t\t\tcgroup_file_show\n\t\t\t\tkernfs_show\n\t\t\t\t// inactive kn\n\t\t\t\tkernfs_drain_open_files\n\t\t\t\tcft-\u0026gt;release(of);\n\t\t\t\tkfree(ctx);\n\t\t\t\t...\nkernfs_get_active = false\n\t\t\t\techo 1 \u0026gt; cgroup.pressure\n\t\t\t\tkernfs_show\n\t\t\t\tkernfs_activate_one(kn);\nkernfs_fop_poll\nkernfs_get_active = true\ncgroup_file_poll\npsi_trigger_poll\n// UAF\n...\nend: close(fd)\n\nTo address this issue, introduce kernfs_get_active_of() for kernfs open\nfiles to obtain active references. This function will fail if the open file\nhas been released. Replace kernfs_get_active() with kernfs_get_active_of()\nto prevent further operations on released file descriptors.(CVE-2025-39881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path\n\nIf request_irq() in i40e_vsi_request_irq_msix() fails in an iteration\nlater than the first, the error path wants to free the IRQs requested\nso far. However, it uses the wrong dev_id argument for free_irq(), so\nit does not free the IRQs correctly and instead triggers the warning:\n\n Trying to free already-free IRQ 173\n WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0\n Modules linked in: i40e(+) [...]\n CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)\n Hardware name: [...]\n RIP: 0010:__free_irq+0x192/0x2c0\n [...]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  free_irq+0x32/0x70\n  i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]\n  i40e_vsi_request_irq+0x79/0x80 [i40e]\n  i40e_vsi_open+0x21f/0x2f0 [i40e]\n  i40e_open+0x63/0x130 [i40e]\n  __dev_open+0xfc/0x210\n  __dev_change_flags+0x1fc/0x240\n  netif_change_flags+0x27/0x70\n  do_setlink.isra.0+0x341/0xc70\n  rtnl_newlink+0x468/0x860\n  rtnetlink_rcv_msg+0x375/0x450\n  netlink_rcv_skb+0x5c/0x110\n  netlink_unicast+0x288/0x3c0\n  netlink_sendmsg+0x20d/0x430\n  ____sys_sendmsg+0x3a2/0x3d0\n  ___sys_sendmsg+0x99/0xe0\n  __sys_sendmsg+0x8a/0xf0\n  do_syscall_64+0x82/0x2c0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  [...]\n  \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nUse the same dev_id for free_irq() as for request_irq().\n\nI tested this with inserting code to fail intentionally.(CVE-2025-39911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Harden uplink netdev access against device unbind\n\nThe function mlx5_uplink_netdev_get() gets the uplink netdevice\npointer from mdev-\u0026gt;mlx5e_res.uplink_netdev. However, the netdevice can\nbe removed and its pointer cleared when unbound from the mlx5_core.eth\ndriver. This results in a NULL pointer, causing a kernel panic.\n\n BUG: unable to handle page fault for address: 0000000000001300\n at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]\n  esw_offloads_enable+0x593/0x910 [mlx5_core]\n  mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]\n  mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]\n  devlink_nl_eswitch_set_doit+0x60/0xd0\n  genl_family_rcv_msg_doit+0xe0/0x130\n  genl_rcv_msg+0x183/0x290\n  netlink_rcv_skb+0x4b/0xf0\n  genl_rcv+0x24/0x40\n  netlink_unicast+0x255/0x380\n  netlink_sendmsg+0x1f3/0x420\n  __sock_sendmsg+0x38/0x60\n  __sys_sendto+0x119/0x180\n  do_syscall_64+0x53/0x1d0\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nEnsure the pointer is valid before use by checking it for NULL. If it\nis valid, immediately call netdev_hold() to take a reference, and\npreventing the netdevice from being freed while it is in use.(CVE-2025-39947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: tuner: xc5000: Fix use-after-free in xc5000_release\n\nThe original code uses cancel_delayed_work() in xc5000_release(), which\ndoes not guarantee that the delayed work item timer_sleep has fully\ncompleted if it was already running. This leads to use-after-free scenarios\nwhere xc5000_release() may free the xc5000_priv while timer_sleep is still\nactive and attempts to dereference the xc5000_priv.\n\nA typical race condition is illustrated below:\n\nCPU 0 (release thread)                 | CPU 1 (delayed work callback)\nxc5000_release()                       | xc5000_do_timer_sleep()\n  cancel_delayed_work()                |\n  hybrid_tuner_release_state(priv)     |\n    kfree(priv)                        |\n                                       |   priv = container_of() // UAF\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the timer_sleep is properly canceled before the xc5000_priv memory\nis deallocated.\n\nA deadlock concern was considered: xc5000_release() is called in a process\ncontext and is not holding any locks that the timer_sleep work item might\nalso need. Therefore, the use of the _sync() variant is safe here.\n\nThis bug was initially identified through static analysis.\n\n[hverkuil: fix typo in Subject: tunner -\u0026gt; tuner](CVE-2025-39994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove\n\nThe original code uses cancel_delayed_work() in flexcop_pci_remove(), which\ndoes not guarantee that the delayed work item irq_check_work has fully\ncompleted if it was already running. This leads to use-after-free scenarios\nwhere flexcop_pci_remove() may free the flexcop_device while irq_check_work\nis still active and attempts to dereference the device.\n\nA typical race condition is illustrated below:\n\nCPU 0 (remove)                         | CPU 1 (delayed work callback)\nflexcop_pci_remove()                   | flexcop_pci_irq_check_work()\n  cancel_delayed_work()                |\n  flexcop_device_kfree(fc_pci-\u0026gt;fc_dev) |\n                                       |   fc = fc_pci-\u0026gt;fc_dev; // UAF\n\nThis is confirmed by a KASAN report:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0\nWrite of size 8 at addr ffff8880093aa8c8 by task bash/135\n...\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x55/0x70\n print_report+0xcf/0x610\n ? __run_timer_base.part.0+0x7d7/0x8c0\n kasan_report+0xb8/0xf0\n ? __run_timer_base.part.0+0x7d7/0x8c0\n __run_timer_base.part.0+0x7d7/0x8c0\n ? __pfx___run_timer_base.part.0+0x10/0x10\n ? __pfx_read_tsc+0x10/0x10\n ? ktime_get+0x60/0x140\n ? lapic_next_event+0x11/0x20\n ? clockevents_program_event+0x1d4/0x2a0\n run_timer_softirq+0xd1/0x190\n handle_softirqs+0x16a/0x550\n irq_exit_rcu+0xaf/0xe0\n sysvec_apic_timer_interrupt+0x70/0x80\n \u0026lt;/IRQ\u0026gt;\n...\n\nAllocated by task 1:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x1be/0x460\n flexcop_device_kmalloc+0x54/0xe0\n flexcop_pci_probe+0x1f/0x9d0\n local_pci_probe+0xdc/0x190\n pci_device_probe+0x2fe/0x470\n really_probe+0x1ca/0x5c0\n __driver_probe_device+0x248/0x310\n driver_probe_device+0x44/0x120\n __driver_attach+0xd2/0x310\n bus_for_each_dev+0xed/0x170\n bus_add_driver+0x208/0x500\n driver_register+0x132/0x460\n do_one_initcall+0x89/0x300\n kernel_init_freeable+0x40d/0x720\n kernel_init+0x1a/0x150\n ret_from_fork+0x10c/0x1a0\n ret_from_fork_asm+0x1a/0x30\n\nFreed by task 135:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3a/0x60\n __kasan_slab_free+0x3f/0x50\n kfree+0x137/0x370\n flexcop_device_kfree+0x32/0x50\n pci_device_remove+0xa6/0x1d0\n device_release_driver_internal+0xf8/0x210\n pci_stop_bus_device+0x105/0x150\n pci_stop_and_remove_bus_device_locked+0x15/0x30\n remove_store+0xcc/0xe0\n kernfs_fop_write_iter+0x2c3/0x440\n vfs_write+0x871/0xd70\n ksys_write+0xee/0x1c0\n do_syscall_64+0xac/0x280\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the delayed work item is properly canceled and any executing delayed\nwork has finished before the device memory is deallocated.\n\nThis bug was initially identified through static analysis. To reproduce\nand test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced\nartificial delays within the flexcop_pci_irq_check_work() function to\nincrease the likelihood of triggering the bug.(CVE-2025-39996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID\n\nPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero\nunique ID.\n\n```\nEach Unit and Terminal within the video function is assigned a unique\nidentification number, the Unit ID (UID) or Terminal ID (TID), contained in\nthe bUnitID or bTerminalID field of the descriptor. The value 0x00 is\nreserved for undefined ID,\n```\n\nIf we add a new entity with id 0 or a duplicated ID, it will be marked\nas UVC_INVALID_ENTITY_ID.\n\nIn a previous attempt commit 3dd075fe8ebb (\u0026quot;media: uvcvideo: Require\nentities to have a non-zero unique ID\u0026quot;), we ignored all the invalid units,\nthis broke a lot of non-compatible cameras. Hopefully we are more lucky\nthis time.\n\nThis also prevents some syzkaller reproducers from triggering warnings due\nto a chain of entities referring to themselves. In one particular case, an\nOutput Unit is connected to an Input Unit, both with the same ID of 1. But\nwhen looking up for the source ID of the Output Unit, that same entity is\nfound instead of the input entity, which leads to such warnings.\n\nIn another case, a backward chain was considered finished as the source ID\nwas 0. Later on, that entity was found, but its pads were not valid.\n\nHere is a sample stack trace for one of those cases.\n\n[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd\n[   20.830206] usb 1-1: Using ep0 maxpacket: 8\n[   20.833501] usb 1-1: config 0 descriptor??\n[   21.038518] usb 1-1: string descriptor 0 read error: -71\n[   21.038893] usb 1-1: Found UVC 0.00 device \u0026lt;unnamed\u0026gt; (2833:0201)\n[   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!\n[   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!\n[   21.042218] ------------[ cut here ]------------\n[   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0\n[   21.043195] Modules linked in:\n[   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444\n[   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[   21.044639] Workqueue: usb_hub_wq hub_event\n[   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0\n[   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 \u0026lt;0f\u0026gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00\n[   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246\n[   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1\n[   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290\n[   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000\n[   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003\n[   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000\n[   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000\n[   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0\n[   21.051136] PKRU: 55555554\n[   21.051331] Call Trace:\n[   21.051480]  \u0026lt;TASK\u0026gt;\n[   21.051611]  ? __warn+0xc4/0x210\n[   21.051861]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.052252]  ? report_bug+0x11b/0x1a0\n[   21.052540]  ? trace_hardirqs_on+0x31/0x40\n[   21.052901]  ? handle_bug+0x3d/0x70\n[   21.053197]  ? exc_invalid_op+0x1a/0x50\n[   21.053511]  ? asm_exc_invalid_op+0x1a/0x20\n[   21.053924]  ? media_create_pad_link+0x91/0x2e0\n[   21.054364]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.054834]  ? media_create_pad_link+0x91/0x2e0\n[   21.055131]  ? _raw_spin_unlock+0x1e/0x40\n[   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210\n[   21.055837]  uvc_mc_register_entities+0x358/0x400\n[   21.056144]  uvc_register_chains+0x1\n---truncated---(CVE-2025-40016)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSquashfs: fix uninit-value in squashfs_get_parent\n\nSyzkaller reports a \u0026quot;KMSAN: uninit-value in squashfs_get_parent\u0026quot; bug.\n\nThis is caused by open_by_handle_at() being called with a file handle\ncontaining an invalid parent inode number.  In particular the inode number\nis that of a symbolic link, rather than a directory.\n\nSquashfs_get_parent() gets called with that symbolic link inode, and\naccesses the parent member field.\n\n\tunsigned int parent_ino = squashfs_i(inode)-\u0026gt;parent;\n\nBecause non-directory inodes in Squashfs do not have a parent value, this\nis uninitialised, and this causes an uninitialised value access.\n\nThe fix is to initialise parent with the invalid inode 0, which will cause\nan EINVAL error to be returned.\n\nRegular inodes used to share the parent field with the block_list_start\nfield.  This is removed in this commit to enable the parent field to\ncontain the invalid inode number 0.(CVE-2025-40049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix crypto buffers in non-linear memory\n\nThe crypto API, through the scatterlist API, expects input buffers to be\nin linear memory.  We handle this with the cifs_sg_set_buf() helper\nthat converts vmalloc\u0026apos;d memory to their corresponding pages.\n\nHowever, when we allocate our aead_request buffer (@creq in\nsmb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly\nputs aead_request-\u0026gt;__ctx in vmalloc area.\n\nAEAD algorithm then uses -\u0026gt;__ctx for its private/internal data and\noperations, and uses sg_set_buf() for such data on a few places.\n\nThis works fine as long as @creq falls into kmalloc zone (small\nrequests) or vmalloc\u0026apos;d memory is still within linear range.\n\nTasks\u0026apos; stacks are vmalloc\u0026apos;d by default (CONFIG_VMAP_STACK=y), so too\nmany tasks will increment the base stacks\u0026apos; addresses to a point where\nvirt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that\nhappens.\n\nIn practice: too many parallel reads and writes on an encrypted mount\nwill trigger this bug.\n\nTo fix this, always alloc @creq with kmalloc() instead.\nAlso drop the @sensitive_size variable/arguments since\nkfree_sensitive() doesn\u0026apos;t need it.\n\nBacktrace:\n\n[  945.272081] ------------[ cut here ]------------\n[  945.272774] kernel BUG at include/linux/scatterlist.h:209!\n[  945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI\n[  945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)\n[  945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014\n[  945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)\n[  945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220\n[  945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff \u0026lt;0f\u0026gt; 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b\n[  945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246\n[  945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030\n[  945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070\n[  945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000\n[  945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070\n[  945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010\n[  945.284407] FS:  0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000\n[  945.285262] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0\n[  945.286683] Call Trace:\n[  945.286952]  \u0026lt;TASK\u0026gt;\n[  945.287184]  ? crypt_message+0x33f/0xad0 [cifs]\n[  945.287719]  crypto_gcm_encrypt+0x36/0xe0\n[  945.288152]  crypt_message+0x54a/0xad0 [cifs]\n[  945.288724]  smb3_init_transform_rq+0x277/0x300 [cifs]\n[  945.289300]  smb_send_rqst+0xa3/0x160 [cifs]\n[  945.289944]  cifs_call_async+0x178/0x340 [cifs]\n[  945.290514]  ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]\n[  945.291177]  smb2_async_writev+0x3e3/0x670 [cifs]\n[  945.291759]  ? find_held_lock+0x32/0x90\n[  945.292212]  ? netfs_advance_write+0xf2/0x310\n[  945.292723]  netfs_advance_write+0xf2/0x310\n[  945.293210]  netfs_write_folio+0x346/0xcc0\n[  945.293689]  ? __pfx__raw_spin_unlock_irq+0x10/0x10\n[  945.294250]  netfs_writepages+0x117/0x460\n[  945.294724]  do_writepages+0xbe/0x170\n[  945.295152]  ? find_held_lock+0x32/0x90\n[  945.295600]  ? kvm_sched_clock_read+0x11/0x20\n[  945.296103]  __writeback_single_inode+0x56/0x4b0\n[  945.296643]  writeback_sb_inodes+0x229/0x550\n[  945.297140]  __writeback_inodes_wb+0x4c/0xe0\n[  945.297642]  wb_writeback+0x2f1/0x3f0\n[  945.298069]  wb_workfn+0x300/0x490\n[  945.298472]  process_one_work+0x1fe/0x590\n[  945.298949]  worker_thread+0x1ce/0x3c0\n[  945.299397]  ? __pfx_worker_thread+0x10/0x10\n[  945.299900]  kthr\n---truncated---(CVE-2025-40052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Disallow dirty tracking if incoherent page walk\n\nDirty page tracking relies on the IOMMU atomically updating the dirty bit\nin the paging-structure entry. For this operation to succeed, the paging-\nstructure memory must be coherent between the IOMMU and the CPU. In\nanother word, if the iommu page walk is incoherent, dirty page tracking\ndoesn\u0026apos;t work.\n\nThe Intel VT-d specification, Section 3.10 \u0026quot;Snoop Behavior\u0026quot; states:\n\n\u0026quot;Remapping hardware encountering the need to atomically update A/EA/D bits\n in a paging-structure entry that is not snooped will result in a non-\n recoverable fault.\u0026quot;\n\nTo prevent an IOMMU from being incorrectly configured for dirty page\ntracking when it is operating in an incoherent mode, mark SSADS as\nsupported only when both ecap_slads and ecap_smpwc are supported.(CVE-2025-40058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix race in do_task() when draining\n\nWhen do_task() exhausts its iteration budget (!ret), it sets the state\nto TASK_STATE_IDLE to reschedule, without a secondary check on the\ncurrent task-\u0026gt;state. This can overwrite the TASK_STATE_DRAINING state\nset by a concurrent call to rxe_cleanup_task() or rxe_disable_task().\n\nWhile state changes are protected by a spinlock, both rxe_cleanup_task()\nand rxe_disable_task() release the lock while waiting for the task to\nfinish draining in the while(!is_done(task)) loop. The race occurs if\ndo_task() hits its iteration limit and acquires the lock in this window.\nThe cleanup logic may then proceed while the task incorrectly\nreschedules itself, leading to a potential use-after-free.\n\nThis bug was introduced during the migration from tasklets to workqueues,\nwhere the special handling for the draining case was lost.\n\nFix this by restoring the original pre-migration behavior. If the state is\nTASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to\nforce a new loop iteration. This allows the task to finish its work, so\nthat a subsequent iteration can reach the switch statement and correctly\ntransition the state to TASK_STATE_DRAINED, stopping the task as intended.(CVE-2025-40061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: start using dst_dev_rcu()\n\nChange icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.\n\nChange ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),\nipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().(CVE-2025-40074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_metrics: use dst_dev_net_rcu()\n\nReplace three dst_dev() with a lockdep enabled helper.(CVE-2025-40075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix mailbox API compatibility by negotiating supported features\n\nThere was backward compatibility in the terms of mailbox API. Various\ndrivers from various OSes supporting 10G adapters from Intel portfolio\ncould easily negotiate mailbox API.\n\nThis convention has been broken since introducing API 1.4.\nCommit 0062e7cc955e (\u0026quot;ixgbevf: add VF IPsec offload code\u0026quot;) added support\nfor IPSec which is specific only for the kernel ixgbe driver. None of the\nrest of the Intel 10G PF/VF drivers supports it. And actually lack of\nsupport was not included in the IPSec implementation - there were no such\ncode paths. No possibility to negotiate support for the feature was\nintroduced along with introduction of the feature itself.\n\nCommit 339f28964147 (\u0026quot;ixgbevf: Add support for new mailbox communication\nbetween PF and VF\u0026quot;) increasing API version to 1.5 did the same - it\nintroduced code supported specifically by the PF ESX driver. It altered API\nversion for the VF driver in the same time not touching the version\ndefined for the PF ixgbe driver. It led to additional discrepancies,\nas the code provided within API 1.6 cannot be supported for Linux ixgbe\ndriver as it causes crashes.\n\nThe issue was noticed some time ago and mitigated by Jake within the commit\nd0725312adf5 (\u0026quot;ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5\u0026quot;).\nAs a result we have regression for IPsec support and after increasing API\nto version 1.6 ixgbevf driver stopped to support ESX MBX.\n\nTo fix this mess add new mailbox op asking PF driver about supported\nfeatures. Basing on a response determine whether to set support for IPSec\nand ESX-specific enhanced mailbox.\n\nNew mailbox op, for compatibility purposes, must be added within new API\nrevision, as API version of OOT PF \u0026amp; VF drivers is already increased to\n1.6 and doesn\u0026apos;t incorporate features negotiate op.\n\nFeatures negotiation mechanism gives possibility to be extended with new\nfeatures when needed in the future.(CVE-2025-40104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping\n\nWhen an invalid value is passed via quirk option, currently\nbytcr_rt5640 driver just ignores and leaves as is, which may lead to\nunepxected results like OOB access.\n\nThis patch adds the sanity check and corrects the input mapping to the\ncertain default value if an invalid value is passed.(CVE-2025-40121)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: use RCU in ip6_xmit()\n\nUse RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent\npossible UAF.(CVE-2025-40135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().\n\nsmc_clc_prfx_set() is called during connect() and not under RCU\nnor RTNL.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()\nafter kernel_getsockname().\n\nNote that the returned value of smc_clc_prfx_set() is not used\nin the caller.\n\nWhile at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()\nnot to touch dst there.(CVE-2025-40139)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().\n\nget_netdev_for_sock() is called during setsockopt(),\nso not under RCU.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dst_dev_rcu().\n\nNote that the only -\u0026gt;ndo_sk_get_lower_dev() user is\nbond_sk_get_lower_dev(), which uses RCU.(CVE-2025-40149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: debugfs: Fix legacy mode page table dump logic\n\nIn legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR\nmaybe uninitialized or zero in that case and may cause oops like:\n\n Oops: general protection fault, probably for non-canonical address\n       0xf00087d3f000f000: 0000 [#1] SMP NOPTI\n CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014\n RIP: 0010:pgtable_walk_level+0x98/0x150\n RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206\n RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e\n RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000\n RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002\n R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000\n R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98\n FS:  0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0\n PKRU: 55555554\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  pgtable_walk_level+0x88/0x150\n  domain_translation_struct_show.isra.0+0x2d9/0x300\n  dev_domain_translation_struct_show+0x20/0x40\n  seq_read_iter+0x12d/0x490\n...\n\nAvoid walking the page table if TT is not 00b or 01b.(CVE-2025-40155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: use RCU in ip6_output()\n\nUse RCU in ip6_output() in order to use dst_dev_rcu() to prevent\npossible UAF.\n\nWe can remove rcu_read_lock()/rcu_read_unlock() pairs\nfrom ip6_finish_output2().(CVE-2025-40158)","status":"published","published":"2025-12-12T11:09:55Z","modified":"2026-08-18T01:19:22.948019711Z","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:45.339366Z"},{"id":"ROOT-OS-DEBIAN-11-CVE-2024-38667","title":"CVE-2024-38667 in linux - Patched by Root","description":"Root has patched CVE-2024-38667 in the linux package for Root:Debian:11. Multiple fixed versions available.","status":"published","published":"2026-08-23T09:13:41Z","modified":"2026-08-23T10:18:12.962234033Z","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:53:29.077857Z"},{"id":"UBUNTU-CVE-2024-38667","description":"In the Linux kernel, the following vulnerability has been resolved: riscv: prevent pt_regs corruption for secondary idle threads Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted. Similar issue has been fixed for the primary hart, see c7cdd96eca28 (\"riscv: prevent stack corruption by reserving task_pt_regs(p) early\"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context.","status":"published","published":"2024-06-24T14:15:00Z","modified":"2026-11-11T09:38:23.51236988Z","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-11T10:00:00.360641Z"},{"id":"CVE-2024-38667","title":"riscv: prevent pt_regs corruption for secondary idle threads","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: prevent pt_regs corruption for secondary idle threads\n\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\n\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\"riscv: prevent stack corruption by reserving task_pt_regs(p) early\").\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.","status":"published","published":"2024-06-24T13:52:25.399Z","modified":"2026-10-28T02:31:12.843329038Z","updated_at":"2026-11-02T15:44:41.618074Z"},{"id":"MGASA-2024-0263","title":"Updated kernel kmod-xtables-addons kmod-virtualbox dwarves packages fix security vulnerabilities","description":"Upstream kernel version 6.6.37 fix bugs and vulnerabilities.\nThe dwarves, 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-07-13T07:54:44Z","modified":"2026-04-16T04:42:07.647203406Z","updated_at":"2026-11-02T15:49:42.684501Z"},{"id":"MGASA-2024-0266","title":"Updated kernel-linus packages fix security vulnerabilities","description":"Vanilla upstream kernel version 6.6.37 fix bugs and vulnerabilities.\nFor information about the vulnerabilities see the links.\n","status":"published","published":"2024-07-14T05:23:38Z","modified":"2026-04-16T04:42:58.217738372Z","updated_at":"2026-11-02T15:49:42.684501Z"},{"id":"USN-6999-1","title":"linux, linux-aws, linux-gcp, linux-gke, linux-ibm, linux-lowlatency, linux-oem-6.8, linux-oracle vulnerabilities","description":"\nChenyuan Yang discovered that the CEC driver driver in the Linux kernel\ncontained a use-after-free vulnerability. A local attacker could use this\nto cause a denial of service (system crash) or possibly execute arbitrary\ncode. (CVE-2024-23848)\n\nIt was discovered that the JFS file system contained an out-of-bounds read\nvulnerability when printing xattr debug information. A local attacker could\nuse this to cause a denial of service (system crash). (CVE-2024-40902)\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  - ARM64 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - Null block device driver;\n  - Character device driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - CPU frequency scaling framework;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Buffer Sharing and Synchronization framework;\n  - DMA engine subsystem;\n  - EFI core;\n  - FPGA Framework;\n  - GPU drivers;\n  - Greybus drivers;\n  - HID subsystem;\n  - HW tracing;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - Input Device (Mouse) drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Microchip PCI driver;\n  - VMware VMCI Driver;\n  - Network drivers;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - PTP clock framework;\n  - S/390 drivers;\n  - SCSI drivers;\n  - SoundWire subsystem;\n  - Sonic Silicon Backplane drivers;\n  - Greybus lights staging drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - USB subsystem;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Watchdog drivers;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - JFS file system;\n  - Network file system server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Tracing file system;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - Core kernel;\n  - BPF subsystem;\n  - Kernel debugger infrastructure;\n  - DMA mapping infrastructure;\n  - IRQ subsystem;\n  - Memory management;\n  - 9P file system network protocol;\n  - Amateur Radio drivers;\n  - B.A.T.M.A.N. meshing protocol;\n  - Ethernet bridge;\n  - Networking core;\n  - Ethtool driver;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - NET/ROM layer;\n  - NFC subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - Unix domain sockets;\n  - Wireless networking;\n  - XFRM subsystem;\n  - AppArmor security module;\n  - Integrity Measurement Architecture(IMA) framework;\n  - Landlock security;\n  - Linux Security Modules (LSM) Framework;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - ALSA framework;\n  - HD-audio driver;\n  - SOF drivers;\n  - KVM core;\n(CVE-2024-40911, CVE-2024-37356, CVE-2024-40935, CVE-2024-40944,\nCVE-2024-41003, CVE-2024-40990, CVE-2024-40952, CVE-2024-40940,\nCVE-2024-40930, CVE-2024-40985, CVE-2024-40941, CVE-2024-38630,\nCVE-2024-39466, CVE-2024-40933, CVE-2024-38624, CVE-2024-40924,\nCVE-2024-40945, CVE-2024-40899, CVE-2024-38622, CVE-2024-40979,\nCVE-2024-36484, CVE-2024-41004, CVE-2024-39474, CVE-2022-48772,\nCVE-2024-36244, CVE-2024-38664, CVE-2024-40925, CVE-2024-40980,\nCVE-2024-39480, CVE-2024-36270, CVE-2024-40936, CVE-2024-40904,\nCVE-2024-38635, CVE-2024-40927, CVE-2024-36481, CVE-2024-40929,\nCVE-2024-40958, CVE-2024-36978, CVE-2024-40992, CVE-2024-40908,\nCVE-2024-39504, CVE-2024-41001, CVE-2024-40967, CVE-2023-52884,\nCVE-2024-40997, CVE-2024-40903, CVE-2024-40913, CVE-2024-34030,\nCVE-2024-39473, CVE-2024-40966, CVE-2024-40951, CVE-2024-40902,\nCVE-2024-40982, CVE-2024-40923, CVE-2024-39467, CVE-2024-40910,\nCVE-2024-40909, CVE-2024-39463, CVE-2024-40974, CVE-2024-41002,\nCVE-2024-39464, CVE-2024-39496, CVE-2024-41040, CVE-2024-39469,\nCVE-2024-39500, CVE-2024-39510, CVE-2024-38627, CVE-2024-32936,\nCVE-2024-40975, CVE-2024-38390, CVE-2024-40959, CVE-2024-41006,\nCVE-2024-40986, CVE-2024-40987, CVE-2024-40922, CVE-2024-40983,\nCVE-2024-37354, CVE-2024-38637, CVE-2024-39277, CVE-2024-40943,\nCVE-2024-39371, CVE-2024-40921, CVE-2024-40953, CVE-2024-38634,\nCVE-2024-38659, CVE-2024-39492, CVE-2024-40976, CVE-2024-40906,\nCVE-2024-40965, CVE-2024-38667, CVE-2024-39498, CVE-2024-38628,\nCVE-2024-38661, CVE-2024-38663, CVE-2024-40998, CVE-2024-40948,\nCVE-2024-38306, CVE-2024-40928, CVE-2024-39468, CVE-2024-39494,\nCVE-2024-39505, CVE-2024-40963, CVE-2024-39499, CVE-2024-39506,\nCVE-2024-40995, CVE-2024-39491, CVE-2024-40900, CVE-2024-39478,\nCVE-2024-39490, CVE-2024-39291, CVE-2024-40981, CVE-2024-40926,\nCVE-2024-40939, CVE-2024-38385, CVE-2024-39483, CVE-2024-40989,\nCVE-2024-40955, CVE-2024-39501, CVE-2024-38381, CVE-2024-33621,\nCVE-2024-40964, CVE-2024-42148, CVE-2024-36286, CVE-2024-38629,\nCVE-2024-39509, CVE-2024-39298, CVE-2024-36489, CVE-2024-34777,\nCVE-2024-40957, CVE-2024-40919, CVE-2024-39462, CVE-2024-39495,\nCVE-2024-39497, CVE-2024-38636, CVE-2024-36281, CVE-2024-39479,\nCVE-2024-40932, CVE-2024-36288, CVE-2024-38623, CVE-2024-40969,\nCVE-2024-40931, CVE-2024-36971, CVE-2024-40934, CVE-2024-36015,\nCVE-2024-39485, CVE-2024-40996, CVE-2024-39507, CVE-2024-36973,\nCVE-2024-38625, CVE-2024-39301, CVE-2024-34027, CVE-2024-37026,\nCVE-2024-40960, CVE-2024-37078, CVE-2024-40912, CVE-2024-40988,\nCVE-2024-41005, CVE-2024-39276, CVE-2024-38662, CVE-2024-39502,\nCVE-2024-36479, CVE-2024-40947, CVE-2024-38780, CVE-2024-38388,\nCVE-2024-40917, CVE-2024-36974, CVE-2024-40970, CVE-2024-40901,\nCVE-2024-38384, CVE-2024-39475, CVE-2024-40949, CVE-2024-37021,\nCVE-2024-38633, CVE-2024-39503, CVE-2024-41000, CVE-2024-33847,\nCVE-2024-35247, CVE-2024-40968, CVE-2024-33619, CVE-2024-38619,\nCVE-2024-40984, CVE-2024-36478, CVE-2024-39493, CVE-2024-42078,\nCVE-2024-40954, CVE-2024-40978, CVE-2024-39508, CVE-2024-40915,\nCVE-2024-39489, CVE-2024-40920, CVE-2024-38618, CVE-2024-40938,\nCVE-2024-39296, CVE-2024-40962, CVE-2024-39470, CVE-2024-39481,\nCVE-2024-40977, CVE-2024-38621, CVE-2024-40971, CVE-2024-31076,\nCVE-2024-36972, CVE-2024-39471, CVE-2024-40994, CVE-2024-40973,\nCVE-2024-40916, CVE-2024-40942, CVE-2024-40956, CVE-2024-39465,\nCVE-2024-40914, CVE-2024-40937, CVE-2024-40918, CVE-2024-40905,\nCVE-2024-39488, CVE-2024-38632, CVE-2024-39461, CVE-2024-40999,\nCVE-2024-40972, CVE-2024-36477, CVE-2024-40961)\n","status":"published","published":"2024-09-11T14:36:17Z","modified":"2026-10-26T22:33:53.084634611Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-6999-2","title":"linux-raspi vulnerabilities","description":"Chenyuan Yang discovered that the CEC driver driver in the Linux kernel\ncontained a use-after-free vulnerability. A local attacker could use this\nto cause a denial of service (system crash) or possibly execute arbitrary\ncode. (CVE-2024-23848)\n\nIt was discovered that the JFS file system contained an out-of-bounds read\nvulnerability when printing xattr debug information. A local attacker could\nuse this to cause a denial of service (system crash). (CVE-2024-40902)\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  - ARM64 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - Null block device driver;\n  - Character device driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - CPU frequency scaling framework;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Buffer Sharing and Synchronization framework;\n  - DMA engine subsystem;\n  - EFI core;\n  - FPGA Framework;\n  - GPU drivers;\n  - Greybus drivers;\n  - HID subsystem;\n  - HW tracing;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - Input Device (Mouse) drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Microchip PCI driver;\n  - VMware VMCI Driver;\n  - Network drivers;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - PTP clock framework;\n  - S/390 drivers;\n  - SCSI drivers;\n  - SoundWire subsystem;\n  - Sonic Silicon Backplane drivers;\n  - Greybus lights staging drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - USB subsystem;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Watchdog drivers;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - JFS file system;\n  - Network file system server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Tracing file system;\n  - IOMMU subsystem;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - Core kernel;\n  - BPF subsystem;\n  - Kernel debugger infrastructure;\n  - DMA mapping infrastructure;\n  - IRQ subsystem;\n  - Memory management;\n  - 9P file system network protocol;\n  - Amateur Radio drivers;\n  - B.A.T.M.A.N. meshing protocol;\n  - Ethernet bridge;\n  - Networking core;\n  - Ethtool driver;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - NET/ROM layer;\n  - NFC subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - Unix domain sockets;\n  - Wireless networking;\n  - XFRM subsystem;\n  - AppArmor security module;\n  - Integrity Measurement Architecture(IMA) framework;\n  - Landlock security;\n  - Linux Security Modules (LSM) Framework;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - ALSA framework;\n  - HD-audio driver;\n  - SOF drivers;\n  - KVM core;\n(CVE-2024-40978, CVE-2024-39504, CVE-2024-39483, CVE-2024-36478,\nCVE-2024-40928, CVE-2024-36971, CVE-2024-40947, CVE-2024-31076,\nCVE-2024-40934, CVE-2024-40909, CVE-2024-40962, CVE-2024-38635,\nCVE-2024-38632, CVE-2024-40912, CVE-2024-40967, CVE-2024-39492,\nCVE-2024-40974, CVE-2024-39466, CVE-2024-40939, CVE-2024-40988,\nCVE-2024-40951, CVE-2024-41005, CVE-2024-40968, CVE-2024-39493,\nCVE-2024-40949, CVE-2022-48772, CVE-2024-40944, CVE-2024-40998,\nCVE-2024-39490, CVE-2024-39467, CVE-2024-42078, CVE-2024-40953,\nCVE-2024-40990, CVE-2024-40902, CVE-2024-39461, CVE-2024-39301,\nCVE-2024-36978, CVE-2024-39475, CVE-2024-39496, CVE-2024-40901,\nCVE-2024-40985, CVE-2024-33621, CVE-2024-38663, CVE-2024-39497,\nCVE-2024-40937, CVE-2024-40941, CVE-2024-40987, CVE-2024-40918,\nCVE-2024-32936, CVE-2024-40999, CVE-2024-40938, CVE-2024-39488,\nCVE-2024-39510, CVE-2024-40924, CVE-2024-38661, CVE-2024-40989,\nCVE-2024-39509, CVE-2024-40983, CVE-2024-39471, CVE-2024-39502,\nCVE-2024-39508, CVE-2024-39371, CVE-2024-40982, CVE-2024-40910,\nCVE-2024-40903, CVE-2024-39296, CVE-2024-39507, CVE-2024-40906,\nCVE-2024-37354, CVE-2024-40905, CVE-2024-34027, CVE-2024-38618,\nCVE-2024-40900, CVE-2024-39469, CVE-2024-38662, CVE-2024-35247,\nCVE-2024-40922, CVE-2024-40926, CVE-2024-39503, CVE-2024-40899,\nCVE-2024-40977, CVE-2024-38634, CVE-2024-40933, CVE-2024-40992,\nCVE-2024-40904, CVE-2024-36479, CVE-2024-40996, CVE-2024-40957,\nCVE-2024-40931, CVE-2024-39291, CVE-2024-38780, CVE-2024-39277,\nCVE-2024-38628, CVE-2024-40932, CVE-2024-41004, CVE-2024-33847,\nCVE-2024-40972, CVE-2024-40945, CVE-2023-52884, CVE-2024-38664,\nCVE-2024-39462, CVE-2024-40965, CVE-2024-38388, CVE-2024-40916,\nCVE-2024-36489, CVE-2024-40975, CVE-2024-40942, CVE-2024-40995,\nCVE-2024-40997, CVE-2024-38385, CVE-2024-40911, CVE-2024-39474,\nCVE-2024-39470, CVE-2024-41000, CVE-2024-36015, CVE-2024-38633,\nCVE-2024-40943, CVE-2024-39489, CVE-2024-36477, CVE-2024-39491,\nCVE-2024-40919, CVE-2024-40914, CVE-2024-40966, CVE-2024-41002,\nCVE-2024-40960, CVE-2024-38624, CVE-2024-40964, CVE-2024-40936,\nCVE-2024-40913, CVE-2024-40955, CVE-2024-37026, CVE-2024-38384,\nCVE-2024-37078, CVE-2024-36244, CVE-2024-38622, CVE-2024-39485,\nCVE-2024-39479, CVE-2024-39505, CVE-2024-36973, CVE-2024-39498,\nCVE-2024-40908, CVE-2024-37356, CVE-2024-39480, CVE-2024-38381,\nCVE-2024-40940, CVE-2024-40980, CVE-2024-39276, CVE-2024-39499,\nCVE-2024-36484, CVE-2024-38636, CVE-2024-38390, CVE-2024-38619,\nCVE-2024-39478, CVE-2024-40959, CVE-2024-36288, CVE-2024-40935,\nCVE-2024-41006, CVE-2024-38625, CVE-2024-36972, CVE-2024-39298,\nCVE-2024-39468, CVE-2024-40970, CVE-2024-37021, CVE-2024-40981,\nCVE-2024-40921, CVE-2024-34777, CVE-2024-39500, CVE-2024-40927,\nCVE-2024-40979, CVE-2024-38627, CVE-2024-39501, CVE-2024-39481,\nCVE-2024-40917, CVE-2024-40956, CVE-2024-42148, CVE-2024-36481,\nCVE-2024-40925, CVE-2024-40986, CVE-2024-40948, CVE-2024-41003,\nCVE-2024-39506, CVE-2024-40952, CVE-2024-38306, CVE-2024-40971,\nCVE-2024-41001, CVE-2024-40973, CVE-2024-36281, CVE-2024-40923,\nCVE-2024-39473, CVE-2024-38637, CVE-2024-40984, CVE-2024-39463,\nCVE-2024-41040, CVE-2024-38623, CVE-2024-40954, CVE-2024-36286,\nCVE-2024-38667, CVE-2024-39465, CVE-2024-40915, CVE-2024-33619,\nCVE-2024-40920, CVE-2024-40969, CVE-2024-38659, CVE-2024-34030,\nCVE-2024-38630, CVE-2024-40976, CVE-2024-36974, CVE-2024-40930,\nCVE-2024-39464, CVE-2024-38621, CVE-2024-40958, CVE-2024-40994,\nCVE-2024-39494, CVE-2024-40961, CVE-2024-39495, CVE-2024-40963,\nCVE-2024-36270, CVE-2024-38629, CVE-2024-40929)\n","status":"published","published":"2024-09-23T15:33:39Z","modified":"2026-10-26T22:33:08.126007801Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7004-1","title":"linux-azure vulnerabilities","description":"\nChenyuan Yang discovered that the CEC driver driver in the Linux kernel\ncontained a use-after-free vulnerability. A local attacker could use this\nto cause a denial of service (system crash) or possibly execute arbitrary\ncode. (CVE-2024-23848)\n\nIt was discovered that the JFS file system contained an out-of-bounds read\nvulnerability when printing xattr debug information. A local attacker could\nuse this to cause a denial of service (system crash). (CVE-2024-40902)\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  - ARM64 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - Null block device driver;\n  - Character device driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - CPU frequency scaling framework;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Buffer Sharing and Synchronization framework;\n  - DMA engine subsystem;\n  - EFI core;\n  - FPGA Framework;\n  - GPU drivers;\n  - Greybus drivers;\n  - HID subsystem;\n  - HW tracing;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - Input Device (Mouse) drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Microchip PCI driver;\n  - VMware VMCI Driver;\n  - Network drivers;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - PTP clock framework;\n  - S/390 drivers;\n  - SCSI drivers;\n  - SoundWire subsystem;\n  - Sonic Silicon Backplane drivers;\n  - Greybus lights staging drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - USB subsystem;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Watchdog drivers;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - JFS file system;\n  - Network file system server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Tracing file system;\n  - IOMMU subsystem;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - Core kernel;\n  - BPF subsystem;\n  - Kernel debugger infrastructure;\n  - DMA mapping infrastructure;\n  - IRQ subsystem;\n  - Memory management;\n  - 9P file system network protocol;\n  - Amateur Radio drivers;\n  - B.A.T.M.A.N. meshing protocol;\n  - Ethernet bridge;\n  - Networking core;\n  - Ethtool driver;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - NET/ROM layer;\n  - NFC subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - Unix domain sockets;\n  - Wireless networking;\n  - XFRM subsystem;\n  - AppArmor security module;\n  - Integrity Measurement Architecture(IMA) framework;\n  - Landlock security;\n  - Linux Security Modules (LSM) Framework;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - ALSA framework;\n  - HD-audio driver;\n  - SOF drivers;\n  - KVM core;\n(CVE-2024-36270, CVE-2024-38627, CVE-2024-39508, CVE-2024-41001,\nCVE-2024-38634, CVE-2024-40979, CVE-2024-40903, CVE-2024-34030,\nCVE-2024-38621, CVE-2024-34027, CVE-2024-39504, CVE-2024-38385,\nCVE-2024-36288, CVE-2024-39301, CVE-2024-38628, CVE-2024-42270,\nCVE-2024-39507, CVE-2024-36286, CVE-2024-40960, CVE-2024-36479,\nCVE-2024-41002, CVE-2024-36974, CVE-2024-40943, CVE-2024-40976,\nCVE-2024-38662, CVE-2024-40995, CVE-2024-39497, CVE-2024-31076,\nCVE-2024-39371, CVE-2024-40983, CVE-2024-40985, CVE-2024-38618,\nCVE-2024-40914, CVE-2024-40989, CVE-2024-40973, CVE-2024-38663,\nCVE-2024-39463, CVE-2024-38633, CVE-2024-36978, CVE-2024-40970,\nCVE-2024-40932, CVE-2024-39480, CVE-2024-39471, CVE-2024-40962,\nCVE-2024-40986, CVE-2024-40937, CVE-2024-39469, CVE-2024-40904,\nCVE-2024-39466, CVE-2024-38388, CVE-2024-39494, CVE-2024-41004,\nCVE-2024-38381, CVE-2022-48772, CVE-2024-33847, CVE-2024-40969,\nCVE-2024-40957, CVE-2024-40933, CVE-2024-37354, CVE-2024-39468,\nCVE-2024-40917, CVE-2024-38623, CVE-2024-40958, CVE-2024-39502,\nCVE-2024-38384, CVE-2024-39506, CVE-2024-40940, CVE-2024-34777,\nCVE-2024-41005, CVE-2024-39470, CVE-2024-39464, CVE-2024-39492,\nCVE-2024-38629, CVE-2024-39505, CVE-2024-40952, CVE-2024-40941,\nCVE-2024-39474, CVE-2024-38664, CVE-2024-40929, CVE-2024-39489,\nCVE-2024-40953, CVE-2024-40916, CVE-2024-40911, CVE-2024-32936,\nCVE-2024-40934, CVE-2024-37078, CVE-2024-39483, CVE-2024-40967,\nCVE-2024-40924, CVE-2024-39462, CVE-2024-40981, CVE-2024-36281,\nCVE-2024-39291, CVE-2024-39481, CVE-2024-40978, CVE-2024-38622,\nCVE-2024-39503, CVE-2024-40956, CVE-2023-52884, CVE-2024-39498,\nCVE-2024-38661, CVE-2024-40918, CVE-2024-39479, CVE-2024-40915,\nCVE-2024-39501, CVE-2024-39488, CVE-2024-40925, CVE-2024-40930,\nCVE-2024-40961, CVE-2024-40951, CVE-2024-38636, CVE-2024-39491,\nCVE-2024-39495, CVE-2024-39509, CVE-2024-40947, CVE-2024-36477,\nCVE-2024-36478, CVE-2024-42148, CVE-2024-39473, CVE-2024-39510,\nCVE-2024-40923, CVE-2024-38624, CVE-2024-38659, CVE-2024-36971,\nCVE-2024-38625, CVE-2024-40913, CVE-2024-35247, CVE-2024-36481,\nCVE-2024-36484, CVE-2024-40928, CVE-2024-40927, CVE-2024-40944,\nCVE-2024-39485, CVE-2024-36244, CVE-2024-40910, CVE-2024-40945,\nCVE-2024-33621, CVE-2024-38667, CVE-2024-40992, CVE-2024-40908,\nCVE-2024-40901, CVE-2024-40906, CVE-2024-38390, CVE-2024-40900,\nCVE-2024-41006, CVE-2024-40968, CVE-2024-40966, CVE-2024-40977,\nCVE-2024-33619, CVE-2024-39496, CVE-2024-38630, CVE-2024-40920,\nCVE-2024-39499, CVE-2024-40899, CVE-2024-41003, CVE-2024-40964,\nCVE-2024-40922, CVE-2024-38632, CVE-2024-40931, CVE-2024-40982,\nCVE-2024-40971, CVE-2024-39277, CVE-2024-39467, CVE-2024-36015,\nCVE-2024-40954, CVE-2024-40938, CVE-2024-40921, CVE-2024-39296,\nCVE-2024-41040, CVE-2024-40965, CVE-2024-39465, CVE-2024-40984,\nCVE-2024-39478, CVE-2024-40990, CVE-2024-40926, CVE-2024-40980,\nCVE-2024-40905, CVE-2024-39475, CVE-2024-40959, CVE-2024-40902,\nCVE-2024-38780, CVE-2024-40935, CVE-2024-37021, CVE-2024-40997,\nCVE-2024-40936, CVE-2024-40987, CVE-2024-40939, CVE-2024-37026,\nCVE-2024-36973, CVE-2024-40972, CVE-2024-42078, CVE-2024-38306,\nCVE-2024-40949, CVE-2024-36489, CVE-2024-38637, CVE-2024-40912,\nCVE-2024-39276, CVE-2024-39493, CVE-2024-40994, CVE-2024-40948,\nCVE-2024-36972, CVE-2024-40942, CVE-2024-37356, CVE-2024-38619,\nCVE-2024-40988, CVE-2024-38635, CVE-2024-41000, CVE-2024-40955,\nCVE-2024-40999, CVE-2024-40974, CVE-2024-39490, CVE-2024-39298,\nCVE-2024-40975, CVE-2024-40998, CVE-2024-40996, CVE-2024-40963,\nCVE-2024-40909, CVE-2024-40919, CVE-2024-39500, CVE-2024-39461)\n","status":"published","published":"2024-09-12T13:23:45Z","modified":"2026-10-26T22:33:28.70692352Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7005-1","title":"linux-nvidia, linux-nvidia-lowlatency vulnerabilities","description":"\nChenyuan Yang discovered that the CEC driver driver in the Linux kernel\ncontained a use-after-free vulnerability. A local attacker could use this\nto cause a denial of service (system crash) or possibly execute arbitrary\ncode. (CVE-2024-23848)\n\nIt was discovered that the JFS file system contained an out-of-bounds read\nvulnerability when printing xattr debug information. A local attacker could\nuse this to cause a denial of service (system crash). (CVE-2024-40902)\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  - ARM64 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - Null block device driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - CPU frequency scaling framework;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Buffer Sharing and Synchronization framework;\n  - DMA engine subsystem;\n  - EFI core;\n  - FPGA Framework;\n  - GPU drivers;\n  - Greybus drivers;\n  - HID subsystem;\n  - HW tracing;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - Input Device (Mouse) drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Microchip PCI driver;\n  - VMware VMCI Driver;\n  - Network drivers;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - PTP clock framework;\n  - S/390 drivers;\n  - SCSI drivers;\n  - SoundWire subsystem;\n  - Sonic Silicon Backplane drivers;\n  - Greybus lights staging drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - USB subsystem;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Watchdog drivers;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - JFS file system;\n  - Network file system server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Tracing file system;\n  - IOMMU subsystem;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - Core kernel;\n  - BPF subsystem;\n  - Kernel debugger infrastructure;\n  - DMA mapping infrastructure;\n  - IRQ subsystem;\n  - Memory management;\n  - 9P file system network protocol;\n  - Amateur Radio drivers;\n  - B.A.T.M.A.N. meshing protocol;\n  - Ethernet bridge;\n  - Networking core;\n  - Ethtool driver;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - NET/ROM layer;\n  - NFC subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - Unix domain sockets;\n  - Wireless networking;\n  - XFRM subsystem;\n  - AppArmor security module;\n  - Integrity Measurement Architecture(IMA) framework;\n  - Landlock security;\n  - Linux Security Modules (LSM) Framework;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - ALSA framework;\n  - HD-audio driver;\n  - SOF drivers;\n  - KVM core;\n(CVE-2024-40963, CVE-2024-40994, CVE-2024-36481, CVE-2024-39301,\nCVE-2024-38390, CVE-2024-40976, CVE-2024-40934, CVE-2024-40902,\nCVE-2024-40916, CVE-2024-39298, CVE-2024-38659, CVE-2024-38384,\nCVE-2024-38635, CVE-2024-39494, CVE-2024-40926, CVE-2024-40956,\nCVE-2024-40948, CVE-2024-40920, CVE-2024-38624, CVE-2024-39498,\nCVE-2024-38780, CVE-2024-39503, CVE-2024-40919, CVE-2024-39505,\nCVE-2024-40988, CVE-2024-36972, CVE-2024-36974, CVE-2024-39495,\nCVE-2024-40992, CVE-2024-36015, CVE-2024-38618, CVE-2024-39478,\nCVE-2024-40975, CVE-2024-39507, CVE-2024-39479, CVE-2024-39291,\nCVE-2024-40925, CVE-2024-39493, CVE-2024-41005, CVE-2024-40932,\nCVE-2024-39467, CVE-2024-40973, CVE-2024-38634, CVE-2024-34027,\nCVE-2024-39462, CVE-2024-40949, CVE-2024-40908, CVE-2024-40929,\nCVE-2024-38662, CVE-2024-39489, CVE-2024-40953, CVE-2024-38306,\nCVE-2024-40915, CVE-2024-39470, CVE-2024-40969, CVE-2024-31076,\nCVE-2024-38663, CVE-2024-38629, CVE-2024-38633, CVE-2024-40959,\nCVE-2024-39475, CVE-2024-40947, CVE-2024-40971, CVE-2024-40979,\nCVE-2024-40996, CVE-2024-36484, CVE-2024-40960, CVE-2022-48772,\nCVE-2024-33619, CVE-2024-40923, CVE-2024-41006, CVE-2024-39474,\nCVE-2024-40944, CVE-2024-39473, CVE-2024-39469, CVE-2024-40914,\nCVE-2024-40900, CVE-2023-52884, CVE-2024-40931, CVE-2024-38664,\nCVE-2024-41004, CVE-2024-38636, CVE-2024-41001, CVE-2024-39497,\nCVE-2024-40974, CVE-2024-42078, CVE-2024-40954, CVE-2024-39483,\nCVE-2024-40978, CVE-2024-40952, CVE-2024-39481, CVE-2024-40955,\nCVE-2024-39471, CVE-2024-41000, CVE-2024-40972, CVE-2024-40957,\nCVE-2024-40913, CVE-2024-36478, CVE-2024-40984, CVE-2024-40990,\nCVE-2024-39510, CVE-2024-38381, CVE-2024-39277, CVE-2024-39464,\nCVE-2024-40995, CVE-2024-40905, CVE-2024-40986, CVE-2024-36971,\nCVE-2024-39480, CVE-2024-40938, CVE-2024-39509, CVE-2024-40982,\nCVE-2024-39500, CVE-2024-37026, CVE-2024-40965, CVE-2024-40961,\nCVE-2024-40989, CVE-2024-36973, CVE-2024-39504, CVE-2024-37354,\nCVE-2024-39488, CVE-2024-38661, CVE-2024-40998, CVE-2024-36489,\nCVE-2024-37021, CVE-2024-40917, CVE-2024-36281, CVE-2024-40964,\nCVE-2024-39496, CVE-2024-40980, CVE-2024-39465, CVE-2024-40983,\nCVE-2024-40936, CVE-2024-40899, CVE-2024-40933, CVE-2024-36288,\nCVE-2024-36286, CVE-2024-40987, CVE-2024-40939, CVE-2024-38667,\nCVE-2024-38628, CVE-2024-40977, CVE-2024-39276, CVE-2024-40941,\nCVE-2024-39491, CVE-2024-37078, CVE-2024-36978, CVE-2024-38623,\nCVE-2024-40962, CVE-2024-40935, CVE-2024-40997, CVE-2024-40981,\nCVE-2024-40922, CVE-2024-39461, CVE-2024-40999, CVE-2024-40918,\nCVE-2024-40927, CVE-2024-42148, CVE-2024-39371, CVE-2024-40985,\nCVE-2024-34030, CVE-2024-39485, CVE-2024-39296, CVE-2024-39466,\nCVE-2024-40909, CVE-2024-39492, CVE-2024-39502, CVE-2024-40903,\nCVE-2024-41040, CVE-2024-40968, CVE-2024-41003, CVE-2024-39499,\nCVE-2024-39508, CVE-2024-34777, CVE-2024-38627, CVE-2024-40930,\nCVE-2024-38388, CVE-2024-39490, CVE-2024-40906, CVE-2024-40940,\nCVE-2024-40937, CVE-2024-40911, CVE-2024-38385, CVE-2024-36244,\nCVE-2024-38622, CVE-2024-40958, CVE-2024-41002, CVE-2024-38621,\nCVE-2024-40970, CVE-2024-40904, CVE-2024-40928, CVE-2024-40967,\nCVE-2024-40951, CVE-2024-38637, CVE-2024-37356, CVE-2024-39463,\nCVE-2024-40912, CVE-2024-33847, CVE-2024-39468, CVE-2024-40942,\nCVE-2024-40910, CVE-2024-38625, CVE-2024-35247, CVE-2024-36479,\nCVE-2024-40943, CVE-2024-32936, CVE-2024-38630, CVE-2024-39501,\nCVE-2024-40966, CVE-2024-40921, CVE-2024-40924, CVE-2024-39506,\nCVE-2024-36270, CVE-2024-33621, CVE-2024-40945, CVE-2024-40901,\nCVE-2024-38632, CVE-2024-38619)\n","status":"published","published":"2024-09-12T13:47:54Z","modified":"2026-10-26T22:33:30.162166072Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7005-2","title":"linux-nvidia-6.8 vulnerabilities","description":"\nChenyuan Yang discovered that the CEC driver driver in the Linux kernel\ncontained a use-after-free vulnerability. A local attacker could use this\nto cause a denial of service (system crash) or possibly execute arbitrary\ncode. (CVE-2024-23848)\n\nIt was discovered that the JFS file system contained an out-of-bounds read\nvulnerability when printing xattr debug information. A local attacker could\nuse this to cause a denial of service (system crash). (CVE-2024-40902)\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  - ARM64 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - Null block device driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - CPU frequency scaling framework;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Buffer Sharing and Synchronization framework;\n  - DMA engine subsystem;\n  - EFI core;\n  - FPGA Framework;\n  - GPU drivers;\n  - Greybus drivers;\n  - HID subsystem;\n  - HW tracing;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - Input Device (Mouse) drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Microchip PCI driver;\n  - VMware VMCI Driver;\n  - Network drivers;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - PTP clock framework;\n  - S/390 drivers;\n  - SCSI drivers;\n  - SoundWire subsystem;\n  - Sonic Silicon Backplane drivers;\n  - Greybus lights staging drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - USB subsystem;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Watchdog drivers;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - JFS file system;\n  - Network file system server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Tracing file system;\n  - IOMMU subsystem;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - Core kernel;\n  - BPF subsystem;\n  - Kernel debugger infrastructure;\n  - DMA mapping infrastructure;\n  - IRQ subsystem;\n  - Memory management;\n  - 9P file system network protocol;\n  - Amateur Radio drivers;\n  - B.A.T.M.A.N. meshing protocol;\n  - Ethernet bridge;\n  - Networking core;\n  - Ethtool driver;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - NET/ROM layer;\n  - NFC subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - Unix domain sockets;\n  - Wireless networking;\n  - XFRM subsystem;\n  - AppArmor security module;\n  - Integrity Measurement Architecture(IMA) framework;\n  - Landlock security;\n  - Linux Security Modules (LSM) Framework;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - ALSA framework;\n  - HD-audio driver;\n  - SOF drivers;\n  - KVM core;\n(CVE-2024-39465, CVE-2024-39492, CVE-2024-40976, CVE-2024-40956,\nCVE-2024-39480, CVE-2024-39467, CVE-2024-39478, CVE-2024-39489,\nCVE-2024-41003, CVE-2024-39510, CVE-2024-39498, CVE-2024-40994,\nCVE-2024-40937, CVE-2024-39488, CVE-2024-40990, CVE-2024-40955,\nCVE-2024-40905, CVE-2024-39496, CVE-2024-36478, CVE-2024-40920,\nCVE-2024-40954, CVE-2024-32936, CVE-2024-40919, CVE-2024-40947,\nCVE-2024-40975, CVE-2024-39481, CVE-2024-40983, CVE-2024-39276,\nCVE-2024-37026, CVE-2024-40980, CVE-2022-48772, CVE-2024-39470,\nCVE-2024-40951, CVE-2024-40927, CVE-2024-38635, CVE-2024-40974,\nCVE-2024-39468, CVE-2024-38384, CVE-2024-37354, CVE-2024-40992,\nCVE-2024-40934, CVE-2024-40925, CVE-2024-40935, CVE-2024-39473,\nCVE-2024-40910, CVE-2024-40979, CVE-2024-39501, CVE-2024-38628,\nCVE-2024-39298, CVE-2024-40909, CVE-2024-38629, CVE-2024-41000,\nCVE-2024-40989, CVE-2024-40924, CVE-2024-40943, CVE-2024-41006,\nCVE-2024-38621, CVE-2024-39462, CVE-2024-38633, CVE-2024-40911,\nCVE-2024-39499, CVE-2024-40968, CVE-2024-40985, CVE-2024-40977,\nCVE-2024-39461, CVE-2024-40966, CVE-2024-40944, CVE-2024-39466,\nCVE-2024-38630, CVE-2024-41040, CVE-2024-39503, CVE-2024-36974,\nCVE-2024-39464, CVE-2024-40960, CVE-2024-40982, CVE-2024-36281,\nCVE-2024-40899, CVE-2024-39291, CVE-2024-40908, CVE-2024-35247,\nCVE-2024-41001, CVE-2024-39493, CVE-2024-39474, CVE-2024-39485,\nCVE-2024-36286, CVE-2024-38622, CVE-2024-36244, CVE-2024-40933,\nCVE-2024-40940, CVE-2024-39491, CVE-2024-38637, CVE-2024-38388,\nCVE-2024-40999, CVE-2024-33621, CVE-2024-34027, CVE-2024-40945,\nCVE-2024-36484, CVE-2024-40958, CVE-2024-40988, CVE-2024-40915,\nCVE-2024-39494, CVE-2024-40996, CVE-2024-38662, CVE-2024-40961,\nCVE-2024-40916, CVE-2024-40949, CVE-2024-41002, CVE-2024-39497,\nCVE-2024-40986, CVE-2024-40963, CVE-2024-33619, CVE-2024-40918,\nCVE-2024-34030, CVE-2024-33847, CVE-2024-40995, CVE-2024-40981,\nCVE-2024-40942, CVE-2024-40932, CVE-2024-39490, CVE-2024-39495,\nCVE-2024-40959, CVE-2024-39505, CVE-2024-34777, CVE-2024-39471,\nCVE-2023-52884, CVE-2024-40984, CVE-2024-40913, CVE-2024-38618,\nCVE-2024-37356, CVE-2024-40928, CVE-2024-42148, CVE-2024-39469,\nCVE-2024-38623, CVE-2024-40964, CVE-2024-38780, CVE-2024-40970,\nCVE-2024-36489, CVE-2024-36978, CVE-2024-40971, CVE-2024-40929,\nCVE-2024-31076, CVE-2024-40948, CVE-2024-40997, CVE-2024-39371,\nCVE-2024-36973, CVE-2024-40953, CVE-2024-41005, CVE-2024-40965,\nCVE-2024-39463, CVE-2024-39508, CVE-2024-37078, CVE-2024-39509,\nCVE-2024-38390, CVE-2024-38659, CVE-2024-39507, CVE-2024-36015,\nCVE-2024-40921, CVE-2024-40904, CVE-2024-40941, CVE-2024-40957,\nCVE-2024-38619, CVE-2024-40998, CVE-2024-38627, CVE-2024-39277,\nCVE-2024-40939, CVE-2024-40902, CVE-2024-38625, CVE-2024-36972,\nCVE-2024-38385, CVE-2024-38663, CVE-2024-40926, CVE-2024-40952,\nCVE-2024-40973, CVE-2024-40962, CVE-2024-40912, CVE-2024-40900,\nCVE-2024-40931, CVE-2024-36270, CVE-2024-40967, CVE-2024-39506,\nCVE-2024-36288, CVE-2024-38634, CVE-2024-39296, CVE-2024-42078,\nCVE-2024-38381, CVE-2024-40969, CVE-2024-36479, CVE-2024-38636,\nCVE-2024-39504, CVE-2024-40936, CVE-2024-38306, CVE-2024-40987,\nCVE-2024-40906, CVE-2024-40914, CVE-2024-40901, CVE-2024-40930,\nCVE-2024-40917, CVE-2024-39500, CVE-2024-36481, CVE-2024-39479,\nCVE-2024-38667, CVE-2024-39475, CVE-2024-41004, CVE-2024-40903,\nCVE-2024-36971, CVE-2024-38624, CVE-2024-39502, CVE-2024-39483,\nCVE-2024-38632, CVE-2024-40923, CVE-2024-39301, CVE-2024-38661,\nCVE-2024-40938, CVE-2024-40978, CVE-2024-40922, CVE-2024-40972,\nCVE-2024-37021, CVE-2024-38664)\n","status":"published","published":"2024-09-13T11:22:12Z","modified":"2026-10-26T22:33:28.423230775Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7008-1","title":"linux-lowlatency-hwe-6.8 vulnerabilities","description":"\nChenyuan Yang discovered that the CEC driver driver in the Linux kernel\ncontained a use-after-free vulnerability. A local attacker could use this\nto cause a denial of service (system crash) or possibly execute arbitrary\ncode. (CVE-2024-23848)\n\nIt was discovered that the JFS file system contained an out-of-bounds read\nvulnerability when printing xattr debug information. A local attacker could\nuse this to cause a denial of service (system crash). (CVE-2024-40902)\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  - ARM64 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - User-Mode Linux (UML);\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - Null block device driver;\n  - Character device driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - CPU frequency scaling framework;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Buffer Sharing and Synchronization framework;\n  - DMA engine subsystem;\n  - EFI core;\n  - FPGA Framework;\n  - GPU drivers;\n  - Greybus drivers;\n  - HID subsystem;\n  - HW tracing;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - Input Device (Mouse) drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Microchip PCI driver;\n  - VMware VMCI Driver;\n  - MMC subsystem;\n  - Network drivers;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - PTP clock framework;\n  - S/390 drivers;\n  - SCSI drivers;\n  - SoundWire subsystem;\n  - Sonic Silicon Backplane drivers;\n  - Greybus lights staging drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - USB subsystem;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Watchdog drivers;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - JFS file system;\n  - Network file system server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Tracing file system;\n  - IOMMU subsystem;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - Core kernel;\n  - BPF subsystem;\n  - Kernel debugger infrastructure;\n  - DMA mapping infrastructure;\n  - IRQ subsystem;\n  - Memory management;\n  - 9P file system network protocol;\n  - Amateur Radio drivers;\n  - B.A.T.M.A.N. meshing protocol;\n  - Ethernet bridge;\n  - Networking core;\n  - Ethtool driver;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - NET/ROM layer;\n  - NFC subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - Unix domain sockets;\n  - Wireless networking;\n  - XFRM subsystem;\n  - AppArmor security module;\n  - Integrity Measurement Architecture(IMA) framework;\n  - Landlock security;\n  - Linux Security Modules (LSM) Framework;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - ALSA framework;\n  - HD-audio driver;\n  - SOF drivers;\n  - KVM core;\n(CVE-2024-38623, CVE-2024-38662, CVE-2024-39484, CVE-2024-42148,\nCVE-2024-39493, CVE-2024-38637, CVE-2024-40962, CVE-2024-36281,\nCVE-2024-40922, CVE-2024-40958, CVE-2024-40920, CVE-2024-40986,\nCVE-2024-40929, CVE-2024-40967, CVE-2024-39296, CVE-2024-40900,\nCVE-2024-40995, CVE-2024-40974, CVE-2024-40942, CVE-2024-39464,\nCVE-2024-40916, CVE-2024-40952, CVE-2024-40997, CVE-2024-41004,\nCVE-2024-40970, CVE-2024-40911, CVE-2024-40972, CVE-2024-36477,\nCVE-2024-40996, CVE-2024-40988, CVE-2024-38619, CVE-2024-40998,\nCVE-2024-38627, CVE-2024-36971, CVE-2024-37021, CVE-2024-40989,\nCVE-2024-40947, CVE-2024-40957, CVE-2024-39508, CVE-2024-41005,\nCVE-2024-40931, CVE-2024-34777, CVE-2024-38633, CVE-2024-38663,\nCVE-2024-36288, CVE-2024-40955, CVE-2024-40973, CVE-2024-39483,\nCVE-2024-38388, CVE-2024-40976, CVE-2024-38622, CVE-2024-40915,\nCVE-2024-38661, CVE-2024-38306, CVE-2024-39507, CVE-2024-38659,\nCVE-2024-40980, CVE-2024-39301, CVE-2024-40945, CVE-2024-39461,\nCVE-2024-40948, CVE-2024-39465, CVE-2024-38667, CVE-2024-39498,\nCVE-2024-39470, CVE-2024-38629, CVE-2024-40984, CVE-2024-38381,\nCVE-2024-40903, CVE-2024-38636, CVE-2024-36478, CVE-2023-52884,\nCVE-2024-40906, CVE-2024-39371, CVE-2024-38384, CVE-2024-40938,\nCVE-2024-36978, CVE-2024-39502, CVE-2024-39291, CVE-2024-39473,\nCVE-2024-40956, CVE-2024-38618, CVE-2024-40992, CVE-2024-40944,\nCVE-2024-39495, CVE-2024-39494, CVE-2024-38632, CVE-2024-38390,\nCVE-2024-39497, CVE-2024-40899, CVE-2024-40939, CVE-2024-36481,\nCVE-2024-40977, CVE-2024-40961, CVE-2024-33847, CVE-2024-40963,\nCVE-2024-39276, CVE-2024-40902, CVE-2024-40971, CVE-2024-39485,\nCVE-2024-40930, CVE-2024-40985, CVE-2024-39501, CVE-2024-40960,\nCVE-2024-39503, CVE-2024-40909, CVE-2024-36973, CVE-2024-36489,\nCVE-2024-40928, CVE-2024-34027, CVE-2024-40914, CVE-2024-40925,\nCVE-2024-39500, CVE-2024-39292, CVE-2024-40987, CVE-2024-39480,\nCVE-2024-40934, CVE-2024-36270, CVE-2024-38780, CVE-2024-39479,\nCVE-2024-39462, CVE-2024-40966, CVE-2024-39510, CVE-2024-39471,\nCVE-2024-39505, CVE-2024-37078, CVE-2024-40913, CVE-2024-37356,\nCVE-2024-38624, CVE-2024-40917, CVE-2024-39506, CVE-2024-40943,\nCVE-2024-38625, CVE-2024-38664, CVE-2024-40901, CVE-2024-40964,\nCVE-2024-40924, CVE-2024-40918, CVE-2024-36974, CVE-2022-48772,\nCVE-2024-39509, CVE-2024-38385, CVE-2024-40994, CVE-2024-39469,\nCVE-2024-40905, CVE-2024-35247, CVE-2024-41006, CVE-2024-40965,\nCVE-2024-40932, CVE-2024-39491, CVE-2024-39499, CVE-2024-40908,\nCVE-2024-36972, CVE-2024-37026, CVE-2024-40968, CVE-2024-36244,\nCVE-2024-39468, CVE-2024-39489, CVE-2024-33621, CVE-2024-40951,\nCVE-2024-39481, CVE-2024-40959, CVE-2024-40935, CVE-2024-40927,\nCVE-2024-40912, CVE-2024-36479, CVE-2024-39467, CVE-2024-34030,\nCVE-2024-41003, CVE-2024-40936, CVE-2024-39474, CVE-2024-40969,\nCVE-2024-40904, CVE-2024-40937, CVE-2024-40978, CVE-2024-40983,\nCVE-2024-40910, CVE-2024-39466, CVE-2024-40949, CVE-2024-39478,\nCVE-2024-40999, CVE-2024-33619, CVE-2024-38621, CVE-2024-40981,\nCVE-2024-39475, CVE-2024-40954, CVE-2024-41000, CVE-2024-39496,\nCVE-2024-40926, CVE-2024-41040, CVE-2024-39298, CVE-2024-38635,\nCVE-2024-39492, CVE-2024-38628, CVE-2024-39504, CVE-2024-42078,\nCVE-2024-41001, CVE-2024-39463, CVE-2024-36286, CVE-2024-36484,\nCVE-2024-40990, CVE-2024-31076, CVE-2024-38630, CVE-2024-40979,\nCVE-2024-36015, CVE-2024-40923, CVE-2024-40921, CVE-2024-41002,\nCVE-2024-40940, CVE-2024-40975, CVE-2024-40953, CVE-2024-40933,\nCVE-2024-37354, CVE-2024-40982, CVE-2024-38634, CVE-2024-39490,\nCVE-2024-39277, CVE-2024-39488, CVE-2024-40941, CVE-2024-32936,\nCVE-2024-40919)\n","status":"published","published":"2024-09-13T10:51:48Z","modified":"2026-10-26T22:33:27.842467788Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7029-1","title":"linux-hwe-6.8","description":"Chenyuan Yang discovered that the CEC driver driver in the Linux kernel\ncontained a use-after-free vulnerability. A local attacker could use this\nto cause a denial of service (system crash) or possibly execute arbitrary\ncode. (CVE-2024-23848)\n\nIt was discovered that the JFS file system contained an out-of-bounds read\nvulnerability when printing xattr debug information. A local attacker could\nuse this to cause a denial of service (system crash). (CVE-2024-40902)\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  - ARM64 architecture;\n  - MIPS architecture;\n  - PA-RISC architecture;\n  - PowerPC architecture;\n  - RISC-V architecture;\n  - User-Mode Linux (UML);\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - Null block device driver;\n  - Character device driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - CPU frequency scaling framework;\n  - Hardware crypto device drivers;\n  - CXL (Compute Express Link) drivers;\n  - Buffer Sharing and Synchronization framework;\n  - DMA engine subsystem;\n  - EFI core;\n  - FPGA Framework;\n  - GPU drivers;\n  - Greybus drivers;\n  - HID subsystem;\n  - HW tracing;\n  - I2C subsystem;\n  - IIO subsystem;\n  - InfiniBand drivers;\n  - Input Device (Mouse) drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Microchip PCI driver;\n  - VMware VMCI Driver;\n  - MMC subsystem;\n  - Network drivers;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - PTP clock framework;\n  - S/390 drivers;\n  - SCSI drivers;\n  - SoundWire subsystem;\n  - Sonic Silicon Backplane drivers;\n  - Greybus lights staging drivers;\n  - Thermal drivers;\n  - TTY drivers;\n  - USB subsystem;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Watchdog drivers;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - JFS file system;\n  - Network file system server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - SMB network file system;\n  - Tracing file system;\n  - IOMMU subsystem;\n  - Tracing infrastructure;\n  - io_uring subsystem;\n  - Core kernel;\n  - BPF subsystem;\n  - Kernel debugger infrastructure;\n  - DMA mapping infrastructure;\n  - IRQ subsystem;\n  - Memory management;\n  - 9P file system network protocol;\n  - Amateur Radio drivers;\n  - B.A.T.M.A.N. meshing protocol;\n  - Ethernet bridge;\n  - Networking core;\n  - Ethtool driver;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - NET/ROM layer;\n  - NFC subsystem;\n  - Network traffic control;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - Unix domain sockets;\n  - Wireless networking;\n  - XFRM subsystem;\n  - AppArmor security module;\n  - Integrity Measurement Architecture(IMA) framework;\n  - Landlock security;\n  - Linux Security Modules (LSM) Framework;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - ALSA framework;\n  - HD-audio driver;\n  - SOF drivers;\n  - KVM core;\n(CVE-2024-39498, CVE-2024-33847, CVE-2024-39510, CVE-2024-39462,\nCVE-2024-40930, CVE-2024-38634, CVE-2024-40962, CVE-2024-37078,\nCVE-2024-39371, CVE-2024-40972, CVE-2024-41002, CVE-2024-40920,\nCVE-2024-40982, CVE-2024-40915, CVE-2024-40942, CVE-2024-42154,\nCVE-2024-40937, CVE-2024-40967, CVE-2024-40909, CVE-2024-36244,\nCVE-2024-33619, CVE-2024-39277, CVE-2024-40900, CVE-2024-38661,\nCVE-2024-40974, CVE-2024-38618, CVE-2024-32936, CVE-2024-40906,\nCVE-2024-40919, CVE-2024-39470, CVE-2024-38390, CVE-2024-40966,\nCVE-2024-39467, CVE-2024-40938, CVE-2024-39471, CVE-2024-39485,\nCVE-2024-39495, CVE-2024-39492, CVE-2024-39475, CVE-2024-40953,\nCVE-2024-40939, CVE-2024-39493, CVE-2024-38637, CVE-2024-40945,\nCVE-2024-41006, CVE-2024-39461, CVE-2024-40948, CVE-2024-40916,\nCVE-2024-40925, CVE-2024-40956, CVE-2024-40970, CVE-2024-40912,\nCVE-2024-33621, CVE-2024-40989, CVE-2024-36489, CVE-2024-37354,\nCVE-2024-34027, CVE-2024-39506, CVE-2024-39296, CVE-2024-40977,\nCVE-2024-38624, CVE-2024-40983, CVE-2024-40911, CVE-2024-36477,\nCVE-2024-38384, CVE-2024-39507, CVE-2024-38659, CVE-2024-40987,\nCVE-2024-40922, CVE-2024-36978, CVE-2024-38629, CVE-2024-38622,\nCVE-2024-40921, CVE-2024-40903, CVE-2024-38306, CVE-2024-40926,\nCVE-2024-39291, CVE-2024-36286, CVE-2024-40910, CVE-2024-40943,\nCVE-2024-40899, CVE-2024-37356, CVE-2024-40961, CVE-2024-39468,\nCVE-2024-40940, CVE-2024-40931, CVE-2024-38381, CVE-2024-40998,\nCVE-2024-34030, CVE-2024-41000, CVE-2024-40986, CVE-2024-38663,\nCVE-2024-40914, CVE-2024-31076, CVE-2024-42228, CVE-2024-40978,\nCVE-2024-40975, CVE-2024-39494, CVE-2024-40905, CVE-2024-40908,\nCVE-2024-38625, CVE-2024-38388, CVE-2024-40965, CVE-2024-41004,\nCVE-2023-52884, CVE-2024-39484, CVE-2024-40951, CVE-2024-40988,\nCVE-2024-40929, CVE-2024-39491, CVE-2024-40992, CVE-2024-41009,\nCVE-2024-40976, CVE-2024-40917, CVE-2024-39502, CVE-2024-40999,\nCVE-2024-39479, CVE-2024-39505, CVE-2024-40981, CVE-2024-38662,\nCVE-2024-38636, CVE-2024-39496, CVE-2024-39276, CVE-2024-41003,\nCVE-2024-37021, CVE-2024-36972, CVE-2024-38780, CVE-2024-40954,\nCVE-2024-40963, CVE-2024-36478, CVE-2024-39465, CVE-2024-39474,\nCVE-2024-39490, CVE-2024-36484, CVE-2024-36974, CVE-2024-38628,\nCVE-2024-36479, CVE-2024-42078, CVE-2024-40936, CVE-2024-38385,\nCVE-2024-40996, CVE-2024-40901, CVE-2024-40969, CVE-2024-39483,\nCVE-2024-40990, CVE-2024-40947, CVE-2024-40980, CVE-2024-39464,\nCVE-2024-40923, CVE-2024-40933, CVE-2024-39481, CVE-2024-40927,\nCVE-2024-38667, CVE-2024-42159, CVE-2024-38635, CVE-2024-38627,\nCVE-2024-38630, CVE-2024-39504, CVE-2024-34777, CVE-2024-40944,\nCVE-2024-37026, CVE-2024-38633, CVE-2024-40941, CVE-2024-39499,\nCVE-2024-36270, CVE-2024-35247, CVE-2024-40924, CVE-2024-40984,\nCVE-2024-40968, CVE-2024-39489, CVE-2024-39298, CVE-2024-40949,\nCVE-2024-39508, CVE-2024-41001, CVE-2024-40934, CVE-2024-40957,\nCVE-2024-39292, CVE-2024-40979, CVE-2024-39488, CVE-2024-40995,\nCVE-2024-39500, CVE-2024-40918, CVE-2024-36015, CVE-2024-39503,\nCVE-2024-39301, CVE-2024-39466, CVE-2024-42224, CVE-2024-39478,\nCVE-2024-40902, CVE-2024-39509, CVE-2024-39463, CVE-2024-40971,\nCVE-2024-40928, CVE-2024-38664, CVE-2024-39473, CVE-2024-39501,\nCVE-2024-36288, CVE-2024-42148, CVE-2024-38621, CVE-2024-38632,\nCVE-2024-41005, CVE-2024-38619, CVE-2024-36973, CVE-2024-40994,\nCVE-2024-42160, CVE-2024-40960, CVE-2024-40958, CVE-2024-39469,\nCVE-2022-48772, CVE-2024-40964, CVE-2024-40913, CVE-2024-36481,\nCVE-2024-40932, CVE-2024-36971, CVE-2024-40935, CVE-2024-38623,\nCVE-2024-40997, CVE-2024-40952, CVE-2024-40955, CVE-2024-36281,\nCVE-2024-39480, CVE-2024-40904, CVE-2024-40985, CVE-2024-39497,\nCVE-2024-40973, CVE-2024-40959)\n","status":"published","published":"2024-09-23T16:18:42Z","modified":"2026-10-26T22:33:33.280304216Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7166-1","title":"linux, linux-gcp, linux-gcp-5.15, linux-gke, linux-gkeop, linux-ibm, linux-ibm-5.15, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-oracle, linux-oracle-5.15, linux-raspi vulnerabilities","description":"\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  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - ATA over ethernet (AOE) driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - Buffer Sharing and Synchronization framework;\n  - EFI core;\n  - GPIO subsystem;\n  - GPU drivers;\n  - HID subsystem;\n  - I2C subsystem;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Ethernet bonding driver;\n  - Network drivers;\n  - Mellanox network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - STMicroelectronics network drivers;\n  - NTB driver;\n  - Virtio pmem driver;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI subsystem;\n  - SPI subsystem;\n  - Thermal drivers;\n  - USB Device Class drivers;\n  - USB Type-C Port Controller Manager driver;\n  - VFIO drivers;\n  - Virtio Host (VHOST) subsystem;\n  - Framebuffer layer;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - GFS2 file system;\n  - JFS file system;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - Network file system (NFS) superblock;\n  - Bluetooth subsystem;\n  - Network traffic control;\n  - Network sockets;\n  - TCP network protocol;\n  - BPF subsystem;\n  - Perf events;\n  - Kernel thread helper (kthread);\n  - Padata parallel execution mechanism;\n  - Arbitrary resource management;\n  - Static call mechanism;\n  - Tracing infrastructure;\n  - Memory management;\n  - Ethernet bridge;\n  - CAN network layer;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - Netlink;\n  - SCTP protocol;\n  - TIPC protocol;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - AudioScience HPI driver;\n  - Amlogic Meson SoC drivers;\n  - USB sound devices;\n(CVE-2024-49944, CVE-2024-49907, CVE-2024-50062, CVE-2024-36893,\nCVE-2024-49985, CVE-2024-49903, CVE-2024-49886, CVE-2024-50180,\nCVE-2024-47757, CVE-2024-49938, CVE-2024-49902, CVE-2024-47709,\nCVE-2024-49884, CVE-2024-49967, CVE-2024-49977, CVE-2024-47734,\nCVE-2024-49954, CVE-2024-49963, CVE-2024-47747, CVE-2024-50008,\nCVE-2024-47696, CVE-2024-50038, CVE-2024-46695, CVE-2024-47705,\nCVE-2024-49957, CVE-2024-38538, CVE-2024-50019, CVE-2024-38544,\nCVE-2024-50003, CVE-2024-50095, CVE-2024-50000, CVE-2024-49981,\nCVE-2024-49863, CVE-2024-47710, CVE-2024-49983, CVE-2024-26947,\nCVE-2024-46852, CVE-2024-49871, CVE-2024-49936, CVE-2024-47720,\nCVE-2024-49881, CVE-2024-47672, CVE-2024-50040, CVE-2024-49997,\nCVE-2024-50044, CVE-2023-52532, CVE-2024-47740, CVE-2024-44942,\nCVE-2024-49948, CVE-2023-52621, CVE-2024-49959, CVE-2024-47718,\nCVE-2024-50188, CVE-2024-47699, CVE-2024-47756, CVE-2024-47723,\nCVE-2024-46849, CVE-2024-50035, CVE-2024-50189, CVE-2024-47684,\nCVE-2024-49900, CVE-2024-50024, CVE-2024-49851, CVE-2024-49860,\nCVE-2024-49924, CVE-2024-49946, CVE-2024-44940, CVE-2023-52904,\nCVE-2024-47679, CVE-2024-47748, CVE-2023-52917, CVE-2024-47735,\nCVE-2024-46858, CVE-2024-35904, CVE-2024-47673, CVE-2024-49878,\nCVE-2024-47739, CVE-2024-49973, CVE-2024-49935, CVE-2024-49875,\nCVE-2024-49896, CVE-2024-47690, CVE-2024-50007, CVE-2024-49933,\nCVE-2024-49958, CVE-2024-49913, CVE-2024-49883, CVE-2024-47742,\nCVE-2024-41016, CVE-2024-50002, CVE-2024-49969, CVE-2024-46853,\nCVE-2024-50031, CVE-2024-47698, CVE-2024-47749, CVE-2024-50059,\nCVE-2024-49966, CVE-2024-50093, CVE-2024-27072, CVE-2024-50186,\nCVE-2024-49895, CVE-2024-38632, CVE-2024-49995, CVE-2024-38545,\nCVE-2024-38667, CVE-2024-36968, CVE-2024-49952, CVE-2024-50001,\nCVE-2024-47697, CVE-2024-50045, CVE-2024-49856, CVE-2024-49852,\nCVE-2024-47712, CVE-2023-52639, CVE-2024-49975, CVE-2024-42158,\nCVE-2024-49962, CVE-2024-50181, CVE-2024-42156, CVE-2024-46855,\nCVE-2024-47693, CVE-2024-47670, CVE-2024-47706, CVE-2024-50184,\nCVE-2024-49965, CVE-2024-39463, CVE-2024-50191, CVE-2024-49866,\nCVE-2024-49890, CVE-2024-49877, CVE-2024-49879, CVE-2024-49927,\nCVE-2024-50039, CVE-2024-46859, CVE-2024-47674, CVE-2024-50096,\nCVE-2024-50013, CVE-2024-46854, CVE-2024-49868, CVE-2024-49882,\nCVE-2024-47671, CVE-2024-50179, CVE-2024-44931, CVE-2024-50046,\nCVE-2024-50006, CVE-2024-49892, CVE-2024-49949, CVE-2024-42079,\nCVE-2024-46865, CVE-2024-47692, CVE-2024-47713, CVE-2024-47701,\nCVE-2024-49889, CVE-2024-49894, CVE-2024-50015, CVE-2024-49858,\nCVE-2024-49955, CVE-2024-49867, CVE-2024-35951, CVE-2024-50033,\nCVE-2024-49982, CVE-2024-47695, CVE-2024-50049, CVE-2024-49930,\nCVE-2024-50041, CVE-2024-47737, CVE-2024-47685)\n","status":"published","published":"2024-12-17T13:14:37Z","modified":"2026-10-29T20:05:04.760272485Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7166-2","title":"linux-aws, linux-aws-5.15 vulnerabilities","description":"Several 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  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - ATA over ethernet (AOE) driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - Buffer Sharing and Synchronization framework;\n  - EFI core;\n  - GPIO subsystem;\n  - GPU drivers;\n  - HID subsystem;\n  - I2C subsystem;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Ethernet bonding driver;\n  - Network drivers;\n  - Mellanox network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - STMicroelectronics network drivers;\n  - NTB driver;\n  - Virtio pmem driver;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI subsystem;\n  - SPI subsystem;\n  - Thermal drivers;\n  - USB Device Class drivers;\n  - USB Type-C Port Controller Manager driver;\n  - VFIO drivers;\n  - Virtio Host (VHOST) subsystem;\n  - Framebuffer layer;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - GFS2 file system;\n  - JFS file system;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - Network file system (NFS) superblock;\n  - Bluetooth subsystem;\n  - Network traffic control;\n  - Network sockets;\n  - TCP network protocol;\n  - BPF subsystem;\n  - Perf events;\n  - Kernel thread helper (kthread);\n  - Padata parallel execution mechanism;\n  - Arbitrary resource management;\n  - Static call mechanism;\n  - Tracing infrastructure;\n  - Memory management;\n  - Ethernet bridge;\n  - CAN network layer;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - Netlink;\n  - SCTP protocol;\n  - TIPC protocol;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - AudioScience HPI driver;\n  - Amlogic Meson SoC drivers;\n  - USB sound devices;\n(CVE-2024-49944, CVE-2024-49907, CVE-2024-50062, CVE-2024-36893,\nCVE-2024-49985, CVE-2024-49903, CVE-2024-49886, CVE-2024-50180,\nCVE-2024-47757, CVE-2024-49938, CVE-2024-49902, CVE-2024-47709,\nCVE-2024-49884, CVE-2024-49967, CVE-2024-49977, CVE-2024-47734,\nCVE-2024-49954, CVE-2024-49963, CVE-2024-47747, CVE-2024-50008,\nCVE-2024-47696, CVE-2024-50038, CVE-2024-46695, CVE-2024-47705,\nCVE-2024-49957, CVE-2024-38538, CVE-2024-50019, CVE-2024-38544,\nCVE-2024-50003, CVE-2024-50095, CVE-2024-50000, CVE-2024-49981,\nCVE-2024-49863, CVE-2024-47710, CVE-2024-49983, CVE-2024-26947,\nCVE-2024-46852, CVE-2024-49871, CVE-2024-49936, CVE-2024-47720,\nCVE-2024-49881, CVE-2024-47672, CVE-2024-50040, CVE-2024-49997,\nCVE-2024-50044, CVE-2023-52532, CVE-2024-47740, CVE-2024-44942,\nCVE-2024-49948, CVE-2023-52621, CVE-2024-49959, CVE-2024-47718,\nCVE-2024-50188, CVE-2024-47699, CVE-2024-47756, CVE-2024-47723,\nCVE-2024-46849, CVE-2024-50035, CVE-2024-50189, CVE-2024-47684,\nCVE-2024-49900, CVE-2024-50024, CVE-2024-49851, CVE-2024-49860,\nCVE-2024-49924, CVE-2024-49946, CVE-2024-44940, CVE-2023-52904,\nCVE-2024-47679, CVE-2024-47748, CVE-2023-52917, CVE-2024-47735,\nCVE-2024-46858, CVE-2024-35904, CVE-2024-47673, CVE-2024-49878,\nCVE-2024-47739, CVE-2024-49973, CVE-2024-49935, CVE-2024-49875,\nCVE-2024-49896, CVE-2024-47690, CVE-2024-50007, CVE-2024-49933,\nCVE-2024-49958, CVE-2024-49913, CVE-2024-49883, CVE-2024-47742,\nCVE-2024-41016, CVE-2024-50002, CVE-2024-49969, CVE-2024-46853,\nCVE-2024-50031, CVE-2024-47698, CVE-2024-47749, CVE-2024-50059,\nCVE-2024-49966, CVE-2024-50093, CVE-2024-27072, CVE-2024-50186,\nCVE-2024-49895, CVE-2024-38632, CVE-2024-49995, CVE-2024-38545,\nCVE-2024-38667, CVE-2024-36968, CVE-2024-49952, CVE-2024-50001,\nCVE-2024-47697, CVE-2024-50045, CVE-2024-49856, CVE-2024-49852,\nCVE-2024-47712, CVE-2023-52639, CVE-2024-49975, CVE-2024-42158,\nCVE-2024-49962, CVE-2024-50181, CVE-2024-42156, CVE-2024-46855,\nCVE-2024-47693, CVE-2024-47670, CVE-2024-47706, CVE-2024-50184,\nCVE-2024-49965, CVE-2024-39463, CVE-2024-50191, CVE-2024-49866,\nCVE-2024-49890, CVE-2024-49877, CVE-2024-49879, CVE-2024-49927,\nCVE-2024-50039, CVE-2024-46859, CVE-2024-47674, CVE-2024-50096,\nCVE-2024-50013, CVE-2024-46854, CVE-2024-49868, CVE-2024-49882,\nCVE-2024-47671, CVE-2024-50179, CVE-2024-44931, CVE-2024-50046,\nCVE-2024-50006, CVE-2024-49892, CVE-2024-49949, CVE-2024-42079,\nCVE-2024-46865, CVE-2024-47692, CVE-2024-47713, CVE-2024-47701,\nCVE-2024-49889, CVE-2024-49894, CVE-2024-50015, CVE-2024-49858,\nCVE-2024-49955, CVE-2024-49867, CVE-2024-35951, CVE-2024-50033,\nCVE-2024-49982, CVE-2024-47695, CVE-2024-50049, CVE-2024-49930,\nCVE-2024-50041, CVE-2024-47737, CVE-2024-47685)\n","status":"published","published":"2024-12-17T23:22:48Z","modified":"2026-10-29T20:02:44.958502456Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7166-3","title":"linux-hwe-5.15 vulnerabilities","description":"Several 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  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - ATA over ethernet (AOE) driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - Buffer Sharing and Synchronization framework;\n  - EFI core;\n  - GPIO subsystem;\n  - GPU drivers;\n  - HID subsystem;\n  - I2C subsystem;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Ethernet bonding driver;\n  - Network drivers;\n  - Mellanox network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - STMicroelectronics network drivers;\n  - NTB driver;\n  - Virtio pmem driver;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI subsystem;\n  - SPI subsystem;\n  - Thermal drivers;\n  - USB Device Class drivers;\n  - USB Type-C Port Controller Manager driver;\n  - VFIO drivers;\n  - Virtio Host (VHOST) subsystem;\n  - Framebuffer layer;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - GFS2 file system;\n  - JFS file system;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - Network file system (NFS) superblock;\n  - Bluetooth subsystem;\n  - Network traffic control;\n  - Network sockets;\n  - TCP network protocol;\n  - BPF subsystem;\n  - Perf events;\n  - Kernel thread helper (kthread);\n  - Padata parallel execution mechanism;\n  - Arbitrary resource management;\n  - Static call mechanism;\n  - Tracing infrastructure;\n  - Memory management;\n  - Ethernet bridge;\n  - CAN network layer;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - Netlink;\n  - SCTP protocol;\n  - TIPC protocol;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - AudioScience HPI driver;\n  - Amlogic Meson SoC drivers;\n  - USB sound devices;\n(CVE-2024-49944, CVE-2024-49907, CVE-2024-50062, CVE-2024-36893,\nCVE-2024-49985, CVE-2024-49903, CVE-2024-49886, CVE-2024-50180,\nCVE-2024-47757, CVE-2024-49938, CVE-2024-49902, CVE-2024-47709,\nCVE-2024-49884, CVE-2024-49967, CVE-2024-49977, CVE-2024-47734,\nCVE-2024-49954, CVE-2024-49963, CVE-2024-47747, CVE-2024-50008,\nCVE-2024-47696, CVE-2024-50038, CVE-2024-46695, CVE-2024-47705,\nCVE-2024-49957, CVE-2024-38538, CVE-2024-50019, CVE-2024-38544,\nCVE-2024-50003, CVE-2024-50095, CVE-2024-50000, CVE-2024-49981,\nCVE-2024-49863, CVE-2024-47710, CVE-2024-49983, CVE-2024-26947,\nCVE-2024-46852, CVE-2024-49871, CVE-2024-49936, CVE-2024-47720,\nCVE-2024-49881, CVE-2024-47672, CVE-2024-50040, CVE-2024-49997,\nCVE-2024-50044, CVE-2023-52532, CVE-2024-47740, CVE-2024-44942,\nCVE-2024-49948, CVE-2023-52621, CVE-2024-49959, CVE-2024-47718,\nCVE-2024-50188, CVE-2024-47699, CVE-2024-47756, CVE-2024-47723,\nCVE-2024-46849, CVE-2024-50035, CVE-2024-50189, CVE-2024-47684,\nCVE-2024-49900, CVE-2024-50024, CVE-2024-49851, CVE-2024-49860,\nCVE-2024-49924, CVE-2024-49946, CVE-2024-44940, CVE-2023-52904,\nCVE-2024-47679, CVE-2024-47748, CVE-2023-52917, CVE-2024-47735,\nCVE-2024-46858, CVE-2024-35904, CVE-2024-47673, CVE-2024-49878,\nCVE-2024-47739, CVE-2024-49973, CVE-2024-49935, CVE-2024-49875,\nCVE-2024-49896, CVE-2024-47690, CVE-2024-50007, CVE-2024-49933,\nCVE-2024-49958, CVE-2024-49913, CVE-2024-49883, CVE-2024-47742,\nCVE-2024-41016, CVE-2024-50002, CVE-2024-49969, CVE-2024-46853,\nCVE-2024-50031, CVE-2024-47698, CVE-2024-47749, CVE-2024-50059,\nCVE-2024-49966, CVE-2024-50093, CVE-2024-27072, CVE-2024-50186,\nCVE-2024-49895, CVE-2024-38632, CVE-2024-49995, CVE-2024-38545,\nCVE-2024-38667, CVE-2024-36968, CVE-2024-49952, CVE-2024-50001,\nCVE-2024-47697, CVE-2024-50045, CVE-2024-49856, CVE-2024-49852,\nCVE-2024-47712, CVE-2023-52639, CVE-2024-49975, CVE-2024-42158,\nCVE-2024-49962, CVE-2024-50181, CVE-2024-42156, CVE-2024-46855,\nCVE-2024-47693, CVE-2024-47670, CVE-2024-47706, CVE-2024-50184,\nCVE-2024-49965, CVE-2024-39463, CVE-2024-50191, CVE-2024-49866,\nCVE-2024-49890, CVE-2024-49877, CVE-2024-49879, CVE-2024-49927,\nCVE-2024-50039, CVE-2024-46859, CVE-2024-47674, CVE-2024-50096,\nCVE-2024-50013, CVE-2024-46854, CVE-2024-49868, CVE-2024-49882,\nCVE-2024-47671, CVE-2024-50179, CVE-2024-44931, CVE-2024-50046,\nCVE-2024-50006, CVE-2024-49892, CVE-2024-49949, CVE-2024-42079,\nCVE-2024-46865, CVE-2024-47692, CVE-2024-47713, CVE-2024-47701,\nCVE-2024-49889, CVE-2024-49894, CVE-2024-50015, CVE-2024-49858,\nCVE-2024-49955, CVE-2024-49867, CVE-2024-35951, CVE-2024-50033,\nCVE-2024-49982, CVE-2024-47695, CVE-2024-50049, CVE-2024-49930,\nCVE-2024-50041, CVE-2024-47737, CVE-2024-47685)\n","status":"published","published":"2024-12-20T12:51:12Z","modified":"2026-10-29T20:03:10.293918262Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7166-4","title":"linux-xilinx-zynqmp vulnerabilities","description":"Several 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  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - ATA over ethernet (AOE) driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - Buffer Sharing and Synchronization framework;\n  - EFI core;\n  - GPIO subsystem;\n  - GPU drivers;\n  - HID subsystem;\n  - I2C subsystem;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Ethernet bonding driver;\n  - Network drivers;\n  - Mellanox network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - STMicroelectronics network drivers;\n  - NTB driver;\n  - Virtio pmem driver;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI subsystem;\n  - SPI subsystem;\n  - Thermal drivers;\n  - USB Device Class drivers;\n  - USB Type-C Port Controller Manager driver;\n  - VFIO drivers;\n  - Virtio Host (VHOST) subsystem;\n  - Framebuffer layer;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - GFS2 file system;\n  - JFS file system;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - Network file system (NFS) superblock;\n  - Bluetooth subsystem;\n  - Network traffic control;\n  - Network sockets;\n  - TCP network protocol;\n  - BPF subsystem;\n  - Perf events;\n  - Kernel thread helper (kthread);\n  - Padata parallel execution mechanism;\n  - Arbitrary resource management;\n  - Static call mechanism;\n  - Tracing infrastructure;\n  - Memory management;\n  - Ethernet bridge;\n  - CAN network layer;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - Netlink;\n  - SCTP protocol;\n  - TIPC protocol;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - AudioScience HPI driver;\n  - Amlogic Meson SoC drivers;\n  - USB sound devices;\n(CVE-2024-49944, CVE-2024-49907, CVE-2024-50062, CVE-2024-36893,\nCVE-2024-49985, CVE-2024-49903, CVE-2024-49886, CVE-2024-50180,\nCVE-2024-47757, CVE-2024-49938, CVE-2024-49902, CVE-2024-47709,\nCVE-2024-49884, CVE-2024-49967, CVE-2024-49977, CVE-2024-47734,\nCVE-2024-49954, CVE-2024-49963, CVE-2024-47747, CVE-2024-50008,\nCVE-2024-47696, CVE-2024-50038, CVE-2024-46695, CVE-2024-47705,\nCVE-2024-49957, CVE-2024-38538, CVE-2024-50019, CVE-2024-38544,\nCVE-2024-50003, CVE-2024-50095, CVE-2024-50000, CVE-2024-49981,\nCVE-2024-49863, CVE-2024-47710, CVE-2024-49983, CVE-2024-26947,\nCVE-2024-46852, CVE-2024-49871, CVE-2024-49936, CVE-2024-47720,\nCVE-2024-49881, CVE-2024-47672, CVE-2024-50040, CVE-2024-49997,\nCVE-2024-50044, CVE-2023-52532, CVE-2024-47740, CVE-2024-44942,\nCVE-2024-49948, CVE-2023-52621, CVE-2024-49959, CVE-2024-47718,\nCVE-2024-50188, CVE-2024-47699, CVE-2024-47756, CVE-2024-47723,\nCVE-2024-46849, CVE-2024-50035, CVE-2024-50189, CVE-2024-47684,\nCVE-2024-49900, CVE-2024-50024, CVE-2024-49851, CVE-2024-49860,\nCVE-2024-49924, CVE-2024-49946, CVE-2024-44940, CVE-2023-52904,\nCVE-2024-47679, CVE-2024-47748, CVE-2023-52917, CVE-2024-47735,\nCVE-2024-46858, CVE-2024-35904, CVE-2024-47673, CVE-2024-49878,\nCVE-2024-47739, CVE-2024-49973, CVE-2024-49935, CVE-2024-49875,\nCVE-2024-49896, CVE-2024-47690, CVE-2024-50007, CVE-2024-49933,\nCVE-2024-49958, CVE-2024-49913, CVE-2024-49883, CVE-2024-47742,\nCVE-2024-41016, CVE-2024-50002, CVE-2024-49969, CVE-2024-46853,\nCVE-2024-50031, CVE-2024-47698, CVE-2024-47749, CVE-2024-50059,\nCVE-2024-49966, CVE-2024-50093, CVE-2024-27072, CVE-2024-50186,\nCVE-2024-49895, CVE-2024-38632, CVE-2024-49995, CVE-2024-38545,\nCVE-2024-38667, CVE-2024-36968, CVE-2024-49952, CVE-2024-50001,\nCVE-2024-47697, CVE-2024-50045, CVE-2024-49856, CVE-2024-49852,\nCVE-2024-47712, CVE-2023-52639, CVE-2024-49975, CVE-2024-42158,\nCVE-2024-49962, CVE-2024-50181, CVE-2024-42156, CVE-2024-46855,\nCVE-2024-47693, CVE-2024-47670, CVE-2024-47706, CVE-2024-50184,\nCVE-2024-49965, CVE-2024-39463, CVE-2024-50191, CVE-2024-49866,\nCVE-2024-49890, CVE-2024-49877, CVE-2024-49879, CVE-2024-49927,\nCVE-2024-50039, CVE-2024-46859, CVE-2024-47674, CVE-2024-50096,\nCVE-2024-50013, CVE-2024-46854, CVE-2024-49868, CVE-2024-49882,\nCVE-2024-47671, CVE-2024-50179, CVE-2024-44931, CVE-2024-50046,\nCVE-2024-50006, CVE-2024-49892, CVE-2024-49949, CVE-2024-42079,\nCVE-2024-46865, CVE-2024-47692, CVE-2024-47713, CVE-2024-47701,\nCVE-2024-49889, CVE-2024-49894, CVE-2024-50015, CVE-2024-49858,\nCVE-2024-49955, CVE-2024-49867, CVE-2024-35951, CVE-2024-50033,\nCVE-2024-49982, CVE-2024-47695, CVE-2024-50049, CVE-2024-49930,\nCVE-2024-50041, CVE-2024-47737, CVE-2024-47685)\n","status":"published","published":"2025-01-20T12:52:56Z","modified":"2026-10-29T20:02:37.8140987Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7186-1","title":"linux-intel-iotg vulnerabilities","description":"Andy Nguyen discovered that the Bluetooth L2CAP implementation in the Linux\nkernel contained a type-confusion error. A physically proximate remote\nattacker could use this to cause a denial of service (system crash) or\npossibly execute arbitrary code. (CVE-2020-12351)\n\nAndy Nguyen discovered that the Bluetooth A2MP implementation in the Linux\nkernel did not properly initialize memory in some situations. A physically\nproximate remote attacker could use this to expose sensitive information\n(kernel memory). (CVE-2020-12352)\n\nAndy Nguyen discovered that the Bluetooth HCI event packet parser in the\nLinux kernel did not properly handle event advertisements of certain sizes,\nleading to a heap-based buffer overflow. A physically proximate remote\nattacker could use this to cause a denial of service (system crash) or\npossibly execute arbitrary code. (CVE-2020-24490)\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  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - ATA over ethernet (AOE) driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - Buffer Sharing and Synchronization framework;\n  - EFI core;\n  - GPIO subsystem;\n  - GPU drivers;\n  - HID subsystem;\n  - I2C subsystem;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Ethernet bonding driver;\n  - Network drivers;\n  - Mellanox network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - STMicroelectronics network drivers;\n  - NTB driver;\n  - Virtio pmem driver;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI subsystem;\n  - SPI subsystem;\n  - Thermal drivers;\n  - USB Device Class drivers;\n  - USB Type-C Port Controller Manager driver;\n  - VFIO drivers;\n  - Virtio Host (VHOST) subsystem;\n  - Framebuffer layer;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - GFS2 file system;\n  - JFS file system;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - SMB network file system;\n  - Network file system (NFS) superblock;\n  - Bluetooth subsystem;\n  - Network traffic control;\n  - Network sockets;\n  - TCP network protocol;\n  - BPF subsystem;\n  - Perf events;\n  - Kernel thread helper (kthread);\n  - Padata parallel execution mechanism;\n  - Arbitrary resource management;\n  - Static call mechanism;\n  - Tracing infrastructure;\n  - Memory management;\n  - Amateur Radio drivers;\n  - Ethernet bridge;\n  - CAN network layer;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - Netlink;\n  - SCTP protocol;\n  - TIPC protocol;\n  - VMware vSockets driver;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - AudioScience HPI driver;\n  - Amlogic Meson SoC drivers;\n  - USB sound devices;\n(CVE-2024-47720, CVE-2023-52904, CVE-2024-49907, CVE-2024-50049,\nCVE-2024-38667, CVE-2024-47747, CVE-2024-50180, CVE-2024-47756,\nCVE-2024-50015, CVE-2024-49983, CVE-2024-49981, CVE-2024-38538,\nCVE-2024-47735, CVE-2024-50019, CVE-2024-49955, CVE-2024-38545,\nCVE-2024-49902, CVE-2024-46849, CVE-2024-49863, CVE-2024-49944,\nCVE-2024-50189, CVE-2024-49927, CVE-2024-50033, CVE-2024-50045,\nCVE-2024-49977, CVE-2024-35965, CVE-2024-42158, CVE-2024-49913,\nCVE-2024-50038, CVE-2024-49883, CVE-2024-38553, CVE-2024-49868,\nCVE-2024-50264, CVE-2024-46855, CVE-2024-50188, CVE-2024-49952,\nCVE-2024-47718, CVE-2024-50095, CVE-2024-49936, CVE-2024-47734,\nCVE-2024-47713, CVE-2024-47723, CVE-2024-49886, CVE-2024-50044,\nCVE-2024-49985, CVE-2024-49973, CVE-2024-49895, CVE-2024-47693,\nCVE-2024-46858, CVE-2024-50003, CVE-2024-39463, CVE-2024-46852,\nCVE-2024-49867, CVE-2024-49967, CVE-2024-47706, CVE-2024-35904,\nCVE-2024-47698, CVE-2024-47701, CVE-2024-36893, CVE-2024-50031,\nCVE-2024-47699, CVE-2024-47674, CVE-2024-49871, CVE-2024-42156,\nCVE-2024-50179, CVE-2024-49995, CVE-2024-49938, CVE-2024-47692,\nCVE-2024-49975, CVE-2024-47710, CVE-2024-49860, CVE-2024-36968,\nCVE-2024-53057, CVE-2024-50186, CVE-2024-47695, CVE-2024-40973,\nCVE-2024-35966, CVE-2024-46865, CVE-2024-47697, CVE-2024-47757,\nCVE-2023-52639, CVE-2024-47709, CVE-2024-47672, CVE-2024-50040,\nCVE-2024-49890, CVE-2024-49933, CVE-2024-38544, CVE-2024-49858,\nCVE-2024-42079, CVE-2024-46853, CVE-2024-50006, CVE-2024-47670,\nCVE-2024-49896, CVE-2024-50013, CVE-2024-49924, CVE-2024-50093,\nCVE-2024-49884, CVE-2024-49935, CVE-2024-50184, CVE-2024-27072,\nCVE-2024-46695, CVE-2024-49997, CVE-2024-49903, CVE-2024-50001,\nCVE-2024-49969, CVE-2024-49851, CVE-2024-44940, CVE-2024-46859,\nCVE-2024-44942, CVE-2024-49958, CVE-2024-49930, CVE-2024-49949,\nCVE-2024-49881, CVE-2024-47690, CVE-2024-49882, CVE-2024-49875,\nCVE-2024-49959, CVE-2024-46854, CVE-2024-35963, CVE-2024-40910,\nCVE-2024-49965, CVE-2024-50035, CVE-2024-49957, CVE-2024-50059,\nCVE-2024-49894, CVE-2024-47685, CVE-2024-50181, CVE-2024-50024,\nCVE-2024-50062, CVE-2024-43904, CVE-2024-49946, CVE-2024-41016,\nCVE-2023-52621, CVE-2024-26822, CVE-2024-49877, CVE-2024-35967,\nCVE-2024-47742, CVE-2024-47739, CVE-2024-26947, CVE-2024-47748,\nCVE-2024-47737, CVE-2024-44931, CVE-2024-49900, CVE-2024-50041,\nCVE-2024-50046, CVE-2024-50002, CVE-2024-49852, CVE-2024-50039,\nCVE-2024-47679, CVE-2024-47749, CVE-2024-49982, CVE-2024-49878,\nCVE-2024-47712, CVE-2024-47740, CVE-2024-49962, CVE-2024-50096,\nCVE-2024-49948, CVE-2024-50000, CVE-2024-47671, CVE-2024-49892,\nCVE-2024-47673, CVE-2024-35951, CVE-2023-52917, CVE-2024-49889,\nCVE-2024-49954, CVE-2024-38632, CVE-2024-47696, CVE-2024-50007,\nCVE-2024-47705, CVE-2024-50008, CVE-2024-49966, CVE-2024-49856,\nCVE-2023-52532, CVE-2024-49866, CVE-2024-47684, CVE-2024-49963,\nCVE-2024-50191, CVE-2024-49879)\n","status":"published","published":"2025-01-06T21:05:59Z","modified":"2026-10-29T20:02:38.766675676Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7186-2","title":"linux-azure, linux-intel-iotg-5.15 vulnerabilities","description":"Andy Nguyen discovered that the Bluetooth L2CAP implementation in the Linux\nkernel contained a type-confusion error. A physically proximate remote\nattacker could use this to cause a denial of service (system crash) or\npossibly execute arbitrary code. (CVE-2020-12351)\n\nAndy Nguyen discovered that the Bluetooth A2MP implementation in the Linux\nkernel did not properly initialize memory in some situations. A physically\nproximate remote attacker could use this to expose sensitive information\n(kernel memory). (CVE-2020-12352)\n\nAndy Nguyen discovered that the Bluetooth HCI event packet parser in the\nLinux kernel did not properly handle event advertisements of certain sizes,\nleading to a heap-based buffer overflow. A physically proximate remote\nattacker could use this to cause a denial of service (system crash) or\npossibly execute arbitrary code. (CVE-2020-24490)\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  - RISC-V architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Drivers core;\n  - ATA over ethernet (AOE) driver;\n  - TPM device driver;\n  - Clock framework and drivers;\n  - Buffer Sharing and Synchronization framework;\n  - EFI core;\n  - GPIO subsystem;\n  - GPU drivers;\n  - HID subsystem;\n  - I2C subsystem;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Mailbox framework;\n  - Media drivers;\n  - Ethernet bonding driver;\n  - Network drivers;\n  - Mellanox network drivers;\n  - Microsoft Azure Network Adapter (MANA) driver;\n  - STMicroelectronics network drivers;\n  - NTB driver;\n  - Virtio pmem driver;\n  - PCI subsystem;\n  - x86 platform drivers;\n  - S/390 drivers;\n  - SCSI subsystem;\n  - SPI subsystem;\n  - Thermal drivers;\n  - USB Device Class drivers;\n  - USB Type-C Port Controller Manager driver;\n  - VFIO drivers;\n  - Virtio Host (VHOST) subsystem;\n  - Framebuffer layer;\n  - 9P distributed file system;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - File systems infrastructure;\n  - Ext4 file system;\n  - F2FS file system;\n  - GFS2 file system;\n  - JFS file system;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - SMB network file system;\n  - Network file system (NFS) superblock;\n  - Bluetooth subsystem;\n  - Network traffic control;\n  - Network sockets;\n  - TCP network protocol;\n  - BPF subsystem;\n  - Perf events;\n  - Kernel thread helper (kthread);\n  - Padata parallel execution mechanism;\n  - Arbitrary resource management;\n  - Static call mechanism;\n  - Tracing infrastructure;\n  - Memory management;\n  - Amateur Radio drivers;\n  - Ethernet bridge;\n  - CAN network layer;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - Netlink;\n  - SCTP protocol;\n  - TIPC protocol;\n  - VMware vSockets driver;\n  - SELinux security module;\n  - Simplified Mandatory Access Control Kernel framework;\n  - AudioScience HPI driver;\n  - Amlogic Meson SoC drivers;\n  - USB sound devices;\n(CVE-2024-47720, CVE-2023-52904, CVE-2024-49907, CVE-2024-50049,\nCVE-2024-38667, CVE-2024-47747, CVE-2024-50180, CVE-2024-47756,\nCVE-2024-50015, CVE-2024-49983, CVE-2024-49981, CVE-2024-38538,\nCVE-2024-47735, CVE-2024-50019, CVE-2024-49955, CVE-2024-38545,\nCVE-2024-49902, CVE-2024-46849, CVE-2024-49863, CVE-2024-49944,\nCVE-2024-50189, CVE-2024-49927, CVE-2024-50033, CVE-2024-50045,\nCVE-2024-49977, CVE-2024-35965, CVE-2024-42158, CVE-2024-49913,\nCVE-2024-50038, CVE-2024-49883, CVE-2024-38553, CVE-2024-49868,\nCVE-2024-50264, CVE-2024-46855, CVE-2024-50188, CVE-2024-49952,\nCVE-2024-47718, CVE-2024-50095, CVE-2024-49936, CVE-2024-47734,\nCVE-2024-47713, CVE-2024-47723, CVE-2024-49886, CVE-2024-50044,\nCVE-2024-49985, CVE-2024-49973, CVE-2024-49895, CVE-2024-47693,\nCVE-2024-46858, CVE-2024-50003, CVE-2024-39463, CVE-2024-46852,\nCVE-2024-49867, CVE-2024-49967, CVE-2024-47706, CVE-2024-35904,\nCVE-2024-47698, CVE-2024-47701, CVE-2024-36893, CVE-2024-50031,\nCVE-2024-47699, CVE-2024-47674, CVE-2024-49871, CVE-2024-42156,\nCVE-2024-50179, CVE-2024-49995, CVE-2024-49938, CVE-2024-47692,\nCVE-2024-49975, CVE-2024-47710, CVE-2024-49860, CVE-2024-36968,\nCVE-2024-53057, CVE-2024-50186, CVE-2024-47695, CVE-2024-40973,\nCVE-2024-35966, CVE-2024-46865, CVE-2024-47697, CVE-2024-47757,\nCVE-2023-52639, CVE-2024-47709, CVE-2024-47672, CVE-2024-50040,\nCVE-2024-49890, CVE-2024-49933, CVE-2024-38544, CVE-2024-49858,\nCVE-2024-42079, CVE-2024-46853, CVE-2024-50006, CVE-2024-47670,\nCVE-2024-49896, CVE-2024-50013, CVE-2024-49924, CVE-2024-50093,\nCVE-2024-49884, CVE-2024-49935, CVE-2024-50184, CVE-2024-27072,\nCVE-2024-46695, CVE-2024-49997, CVE-2024-49903, CVE-2024-50001,\nCVE-2024-49969, CVE-2024-49851, CVE-2024-44940, CVE-2024-46859,\nCVE-2024-44942, CVE-2024-49958, CVE-2024-49930, CVE-2024-49949,\nCVE-2024-49881, CVE-2024-47690, CVE-2024-49882, CVE-2024-49875,\nCVE-2024-49959, CVE-2024-46854, CVE-2024-35963, CVE-2024-40910,\nCVE-2024-49965, CVE-2024-50035, CVE-2024-49957, CVE-2024-50059,\nCVE-2024-49894, CVE-2024-47685, CVE-2024-50181, CVE-2024-50024,\nCVE-2024-50062, CVE-2024-43904, CVE-2024-49946, CVE-2024-41016,\nCVE-2023-52621, CVE-2024-26822, CVE-2024-49877, CVE-2024-35967,\nCVE-2024-47742, CVE-2024-47739, CVE-2024-26947, CVE-2024-47748,\nCVE-2024-47737, CVE-2024-44931, CVE-2024-49900, CVE-2024-50041,\nCVE-2024-50046, CVE-2024-50002, CVE-2024-49852, CVE-2024-50039,\nCVE-2024-47679, CVE-2024-47749, CVE-2024-49982, CVE-2024-49878,\nCVE-2024-47712, CVE-2024-47740, CVE-2024-49962, CVE-2024-50096,\nCVE-2024-49948, CVE-2024-50000, CVE-2024-47671, CVE-2024-49892,\nCVE-2024-47673, CVE-2024-35951, CVE-2023-52917, CVE-2024-49889,\nCVE-2024-49954, CVE-2024-38632, CVE-2024-47696, CVE-2024-50007,\nCVE-2024-47705, CVE-2024-50008, CVE-2024-49966, CVE-2024-49856,\nCVE-2023-52532, CVE-2024-49866, CVE-2024-47684, CVE-2024-49963,\nCVE-2024-50191, CVE-2024-49879)\n","status":"published","published":"2025-01-09T11:22:33Z","modified":"2026-10-29T20:02:47.045060004Z","updated_at":"2026-11-02T16:58:18.876384Z"},{"id":"USN-7194-1","title":"linux-azure-5.15 vulnerabilities","description":"Andy Nguyen discovered that the Bluetooth L2CAP implementation in the Linux\nkernel contained a type-confusion error. A physically proximate remote\nattacker could use this to cause a denial of service (system crash) or\npossibly execute arbitrary code. (CVE-2020-12351)\n\nAndy Nguyen discovered that the Bluetooth A2MP implementation in the Linux\nkernel did not properly initialize memory in some situations. A physically\nproximate remote attacker could use this to expose sensitive information\n(kernel memory). (CVE-2020-12352)\n\nAndy Nguyen discovered that the Bluetooth HCI event packet parser in the\nLinux kernel did not properly handle event advertisements of certain sizes,\nleading to a heap-based buffer overflow. A physically proximate remote\nattacker could use this to cause a denial of service (system crash) or\npossibly execute arbitrary code. (CVE-2020-24490)\n\nIt was discovered that the CIFS network file system implementation in the\nLinux kernel did not properly validate certain SMB messages, leading to an\nout-of-bounds read vulnerability. An attacker could use this to cause a\ndenial of service (system crash) or possibly expose sensitive information.\n(CVE-2023-6610)\n\nSupraja Sridhara, Benedict Schlüter, Mark Kuhne, Andrin Bertschi, and\nShweta Shinde discovered that the Confidential Computing framework in the\nLinux kernel for x86 platforms did not properly handle 32-bit emulation on\nTDX and SEV. An attacker with access to the VMM could use this to cause a\ndenial of service (guest crash) or possibly execute arbitrary code.\n(CVE-2024-25744)\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  - PowerPC architecture;\n  - RISC-V architecture;\n  - S390 architecture;\n  - User-Mode Linux (UML);\n  - x86 architecture;\n  - Block layer subsystem;\n  - ACPI drivers;\n  - Android drivers;\n  - Serial ATA and Parallel ATA drivers;\n  - ATM drivers;\n  - Drivers core;\n  - ATA over ethernet (AOE) driver;\n  - Null block device driver;\n  - TPM device driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - Buffer Sharing and Synchronization framework;\n  - ARM SCMI message protocol;\n  - EFI core;\n  - GPIO subsystem;\n  - GPU drivers;\n  - HID subsystem;\n  - Hardware monitoring drivers;\n  - I2C subsystem;\n  - I3C 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  - 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  - STMicroelectronics network drivers;\n  - Near Field Communication (NFC) drivers;\n  - NTB driver;\n  - Virtio pmem driver;\n  - NVME drivers;\n  - Device tree and open firmware driver;\n  - Parport drivers;\n  - PCI subsystem;\n  - Pin controllers subsystem;\n  - x86 platform 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  - Userspace I/O drivers;\n  - USB Device Class drivers;\n  - DesignWare USB3 driver;\n  - USB Gadget drivers;\n  - USB Host Controller drivers;\n  - USB Type-C Port Controller Manager driver;\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  - 9P distributed file system;\n  - File systems infrastructure;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - Ext4 file system;\n  - F2FS file system;\n  - GFS2 file system;\n  - JFS file system;\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  - Bitmap API;\n  - Network file system (NFS) superblock;\n  - Objagg library;\n  - Perf events;\n  - Virtio network driver;\n  - Bluetooth subsystem;\n  - KCM (Kernel Connection Multiplexor) sockets driver;\n  - Network traffic control;\n  - Network sockets;\n  - TCP network protocol;\n  - BPF subsystem;\n  - Control group (cgroup);\n  - DMA mapping infrastructure;\n  - Kernel thread helper (kthread);\n  - Locking primitives;\n  - Padata parallel execution mechanism;\n  - RCU subsystem;\n  - Arbitrary resource management;\n  - Scheduler infrastructure;\n  - Static call mechanism;\n  - Tracing infrastructure;\n  - Radix Tree data structure library;\n  - Kernel userspace event delivery library;\n  - Memory management;\n  - Amateur Radio drivers;\n  - Ethernet bridge;\n  - CAN network layer;\n  - Networking core;\n  - Ethtool driver;\n  - IPv4 networking;\n  - IPv6 networking;\n  - IUCV driver;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netfilter;\n  - Netlink;\n  - SCTP protocol;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - VMware vSockets driver;\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  - AudioScience HPI driver;\n  - Amlogic Meson SoC drivers;\n  - SoC audio core drivers;\n  - USB sound devices;\n(CVE-2024-41091, CVE-2024-46800, CVE-2024-49924, CVE-2024-47659,\nCVE-2024-42295, CVE-2024-42284, CVE-2024-38577, CVE-2024-49902,\nCVE-2024-45011, CVE-2024-47673, CVE-2024-38538, CVE-2024-45008,\nCVE-2024-47667, CVE-2024-46832, CVE-2024-43879, CVE-2024-41059,\nCVE-2024-43853, CVE-2024-44940, CVE-2024-44947, CVE-2024-43828,\nCVE-2024-41090, CVE-2024-44944, CVE-2024-43834, CVE-2024-46777,\nCVE-2024-46689, CVE-2024-35965, CVE-2024-42276, CVE-2024-50264,\nCVE-2024-44965, CVE-2024-49977, CVE-2024-42079, CVE-2024-46744,\nCVE-2024-42299, CVE-2024-43909, CVE-2024-41098, CVE-2024-46731,\nCVE-2024-44946, CVE-2024-50024, CVE-2024-49858, CVE-2024-49892,\nCVE-2024-44989, CVE-2024-47663, CVE-2024-49983, CVE-2024-42286,\nCVE-2024-42310, CVE-2024-44974, CVE-2024-43892, CVE-2024-46840,\nCVE-2024-47695, CVE-2024-46780, CVE-2024-46757, CVE-2024-46707,\nCVE-2024-49894, CVE-2024-50007, CVE-2024-47705, CVE-2024-49890,\nCVE-2024-46815, CVE-2024-36968, CVE-2024-40915, CVE-2024-44995,\nCVE-2024-49871, CVE-2024-42265, CVE-2024-42283, CVE-2024-50000,\nCVE-2024-42309, CVE-2024-47748, CVE-2024-35967, CVE-2023-52904,\nCVE-2024-46745, CVE-2024-41016, CVE-2024-49868, CVE-2024-41011,\nCVE-2024-50186, CVE-2024-50033, CVE-2024-38545, CVE-2024-42267,\nCVE-2024-46852, CVE-2024-44987, CVE-2024-46783, CVE-2024-47671,\nCVE-2024-46721, CVE-2024-46853, CVE-2024-43914, CVE-2024-43907,\nCVE-2024-47734, CVE-2024-36484, CVE-2024-46781, CVE-2024-47693,\nCVE-2024-46791, CVE-2024-49913, CVE-2024-49900, CVE-2024-50191,\nCVE-2024-43860, CVE-2024-45018, CVE-2024-46854, CVE-2024-42246,\nCVE-2024-42156, CVE-2024-47660, CVE-2024-49878, CVE-2024-44982,\nCVE-2024-43867, CVE-2024-49938, CVE-2024-47737, CVE-2024-46743,\nCVE-2024-42292, CVE-2024-50181, CVE-2024-41020, CVE-2024-43863,\nCVE-2024-46817, CVE-2024-42281, CVE-2023-52621, CVE-2024-47749,\nCVE-2024-46804, CVE-2024-47747, CVE-2024-50045, CVE-2024-41065,\nCVE-2023-52434, CVE-2024-50095, CVE-2024-45025, CVE-2024-50179,\nCVE-2024-49946, CVE-2024-46782, CVE-2024-43839, CVE-2024-43904,\nCVE-2024-44958, CVE-2024-44934, CVE-2024-45006, CVE-2024-49969,\nCVE-2024-44986, CVE-2024-46752, CVE-2024-35966, CVE-2024-39463,\nCVE-2024-49883, CVE-2024-46805, CVE-2024-44935, CVE-2023-52532,\nCVE-2024-41071, CVE-2024-46807, CVE-2024-43846, CVE-2024-50015,\nCVE-2024-26661, CVE-2024-43841, CVE-2024-46819, CVE-2024-44931,\nCVE-2024-53057, CVE-2024-49982, CVE-2023-52757, CVE-2024-47735,\nCVE-2024-49866, CVE-2024-46763, CVE-2024-45021, CVE-2024-46814,\nCVE-2024-46673, CVE-2024-43873, CVE-2024-49997, CVE-2024-38602,\nCVE-2024-46795, CVE-2024-26822, CVE-2024-47670, CVE-2024-46755,\nCVE-2024-43902, CVE-2024-46859, CVE-2024-43883, CVE-2024-49966,\nCVE-2024-42305, CVE-2024-49959, CVE-2024-42280, CVE-2024-49965,\nCVE-2024-47674, CVE-2024-46723, CVE-2024-50031, CVE-2024-50184,\nCVE-2024-36893, CVE-2024-43875, CVE-2023-52918, CVE-2024-49867,\nCVE-2024-49981, CVE-2024-43861, CVE-2024-49895, CVE-2024-26669,\nCVE-2024-38544, CVE-2024-49973, CVE-2024-41015, CVE-2024-42296,\nCVE-2024-46722, CVE-2024-42158, CVE-2024-49881, CVE-2024-27072,\nCVE-2024-47739, CVE-2024-46828, CVE-2024-46724, CVE-2024-44999,\nCVE-2024-44971, CVE-2024-40973, CVE-2023-52572, CVE-2024-47709,\nCVE-2024-47742, CVE-2024-46818, CVE-2024-50035, CVE-2024-50188,\nCVE-2024-47679, CVE-2024-38667, CVE-2024-41078, CVE-2024-46844,\nCVE-2024-47672, CVE-2024-42306, CVE-2024-46758, CVE-2024-43869,\nCVE-2024-50062, CVE-2024-49875, CVE-2024-41017, CVE-2024-41077,\nCVE-2024-50038, CVE-2024-50013, CVE-2024-46746, CVE-2024-49962,\nCVE-2024-50049, CVE-2023-52751, CVE-2024-47684, CVE-2024-47701,\nCVE-2024-41070, CVE-2024-44942, CVE-2024-35904, CVE-2024-26607,\nCVE-2024-50019, CVE-2024-46714, CVE-2024-46738, CVE-2024-42312,\nCVE-2024-44948, CVE-2024-43890, CVE-2024-43893, CVE-2024-26800,\nCVE-2024-35963, CVE-2024-49884, CVE-2024-49930, CVE-2024-46829,\nCVE-2024-50046, CVE-2024-49985, CVE-2024-41022, CVE-2024-43894,\nCVE-2024-43830, CVE-2024-45009, CVE-2024-35951, CVE-2024-49889,\nCVE-2024-42301, CVE-2024-38632, CVE-2024-42114, CVE-2024-42290,\nCVE-2024-43858, CVE-2024-50002, CVE-2024-41060, CVE-2024-47696,\nCVE-2024-43870, CVE-2024-49948, CVE-2024-46759, CVE-2024-26947,\nCVE-2024-46713, CVE-2024-47740, CVE-2024-44960, CVE-2024-46756,\nCVE-2024-46737, CVE-2024-41068, CVE-2024-46677, CVE-2024-41063,\nCVE-2024-41019, CVE-2023-52917, CVE-2024-38611, CVE-2024-49852,\nCVE-2024-49863, CVE-2024-46739, CVE-2024-43908, CVE-2024-47697,\nCVE-2024-46810, CVE-2024-41072, CVE-2024-42302, CVE-2024-50003,\nCVE-2024-45026, CVE-2024-45028, CVE-2024-42259, CVE-2022-48666,\nCVE-2024-49995, CVE-2024-50093, CVE-2024-46865, CVE-2024-49886,\nCVE-2024-43889, CVE-2024-42285, CVE-2024-50006, CVE-2024-42271,\nCVE-2024-42274, CVE-2024-49957, CVE-2024-42289, CVE-2024-46719,\nCVE-2024-46858, CVE-2024-49958, CVE-2024-50041, CVE-2024-46675,\nCVE-2024-41064, CVE-2024-39472, CVE-2024-42287, CVE-2024-46822,\nCVE-2024-49877, CVE-2024-43849, CVE-2024-50040, CVE-2024-49879,\nCVE-2024-46798, CVE-2024-46855, CVE-2024-49944, CVE-2024-46676,\nCVE-2024-26893, CVE-2024-43835, CVE-2024-47665, CVE-2024-47669,\nCVE-2024-43882, CVE-2024-46740, CVE-2024-49851, CVE-2024-46849,\nCVE-2024-42311, CVE-2024-44985, CVE-2024-47757, CVE-2024-50001,\nCVE-2024-46750, CVE-2024-47706, CVE-2024-50039, CVE-2024-46702,\nCVE-2024-46725, CVE-2024-43817, CVE-2024-49907, CVE-2024-46695,\nCVE-2024-38553, CVE-2024-42272, CVE-2024-49882, CVE-2024-42269,\nCVE-2024-44954, CVE-2024-42318, CVE-2024-42297, CVE-2024-49975,\nCVE-2024-44988, CVE-2024-49963, CVE-2024-47692, CVE-2024-41042,\nCVE-2024-41081, CVE-2024-43854, CVE-2024-46771, CVE-2024-46732,\nCVE-2024-47712, CVE-2024-47699, CVE-2024-49927, CVE-2024-49860,\nCVE-2024-45003, CVE-2024-49954, CVE-2024-42304, CVE-2024-49933,\nCVE-2024-42277, CVE-2024-49955, CVE-2024-47710, CVE-2024-43905,\nCVE-2024-49903, CVE-2024-43856, CVE-2024-50180, CVE-2024-44966,\nCVE-2024-46685, CVE-2024-49935, CVE-2024-44990, CVE-2023-52889,\nCVE-2024-49896, CVE-2024-44969, CVE-2024-50189, CVE-2024-50008,\nCVE-2024-47720, CVE-2024-42313, CVE-2024-44983, CVE-2024-49949,\nCVE-2024-46761, CVE-2024-47690, CVE-2024-50059, CVE-2024-41073,\nCVE-2024-47723, CVE-2024-46747, CVE-2024-49952, CVE-2024-50096,\nCVE-2024-42288, CVE-2024-43871, CVE-2024-42126, CVE-2024-44998,\nCVE-2024-47685, CVE-2024-46679, CVE-2024-43884, CVE-2024-47668,\nCVE-2024-49936, CVE-2024-43829, CVE-2024-47756, CVE-2024-43880,\nCVE-2024-45007, CVE-2024-40910, CVE-2024-50044, CVE-2023-52639,\nCVE-2024-47698, CVE-2024-41012, CVE-2024-49856, CVE-2024-47713,\nCVE-2024-47718, CVE-2024-49967)\n","status":"published","published":"2025-01-09T11:58:43Z","modified":"2026-10-29T20:02:44.581678587Z","updated_at":"2026-11-02T16:58:18.876384Z"}]}}