{"id":"CVE-2025-39725","aliases":["BELL-CVE-2025-39725","DEBIAN-CVE-2025-39725","EUVD-2025-33997","GHSA-qmpx-wcm9-r94f","OESA-2025-2632","OESA-2025-2633","OESA-2025-2634","OESA-2025-2635","OESA-2025-2636","OESA-2025-2659","UBUNTU-CVE-2025-39725","USN-7879-1","USN-7879-2","USN-7879-3","USN-7879-4","USN-7880-1","USN-7934-1"],"status":"published","title":"mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn't in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u003e trigger BUG_ON due to\n  unmap_poisoned_folio couldn't\n   handle large folio\n\n[tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]","severity":{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"primary","from":"nvd"},"epss":{"day":"2026-11-12","score":0.00152,"percentile":0.04457,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-476"],"published":"2025-09-05T17:27:18Z","modified":"2026-11-11T09:39:05Z","fixes":[{"ecosystem":"Alpaquita:25","package":"linux-lts","fixed_in":["6.12.41-r0"],"sources":["osv"]},{"ecosystem":"Alpaquita:stream","package":"linux-lts","fixed_in":["6.18.35-r1"],"sources":["osv"]},{"ecosystem":"Linux","package":"Kernel","fixed_in":["6.12.41","6.15.9"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"linux","fixed_in":["6.12.41-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"linux","fixed_in":["6.16.3-1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-aws-6.14","fixed_in":["6.14.0-1017.17~24.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure-6.14","fixed_in":["6.14.0-1017.17~24.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp-6.14","fixed_in":["6.14.0-1020.21~24.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.14","fixed_in":["6.14.0-1016.16"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-oracle-6.14","fixed_in":["6.14.0-1017.17~24.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"linux-riscv-6.14","fixed_in":["6.14.0-36.36.1~24.04.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-realtime-6.14","fixed_in":["6.14.0-1016.16~24.04.1"],"sources":["osv"]}],"affected":[{"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.12.92-r1"},{"fixed":"6.18.35-r1"}]}]},{"source":"osv","ecosystem":"Linux","package":"Kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.41"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.15.9"}]}]},{"source":"osv","ecosystem":"Debian:13","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.41-1"}]}],"versions":["6.12.38-1"]},{"source":"osv","ecosystem":"Debian:14","package":"linux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.16.3-1"}]}],"versions":["6.12.100-1","6.12.101-1","6.12.105-1","6.12.107-1","6.12.111-1","6.12.113-1","6.12.38-1","6.12.41-1","6.12.43-1","6.12.43-1~bpo12+1","6.12.48-1","6.12.57-1","6.12.57-1~bpo12+1","6.12.63-1","6.12.63-1~bpo12+1","6.12.69-1","6.12.69-1~bpo12+1","6.12.73-1","6.12.73-1~bpo12+1","6.12.74-1","6.12.74-2","6.12.74-2~bpo12+1","6.12.85-1","6.12.85-1~bpo12+1","6.12.86-1","6.12.86-1~bpo12+1","6.12.88-1","6.12.88-1~bpo12+1","6.12.90-1","6.12.90-1~bpo12+1","6.12.90-2","6.12.90-2~bpo12+1","6.12.94-1","6.12.94-1~bpo12+1","6.12.95-1","6.12.95-1~bpo12+1","6.12.96-1","6.13.10-1~exp1","6.13.11-1~exp1","6.13.2-1~exp1","6.13.3-1~exp1","6.13.4-1~exp1","6.13.5-1~exp1","6.13.6-1~exp1","6.13.7-1~exp1","6.13.8-1~exp1","6.13.9-1~exp1","6.13~rc6-1~exp1","6.13~rc7-1~exp1","6.14.3-1~exp1","6.14.5-1~exp1","6.14.6-1~exp1","6.15-1~exp1","6.15.1-1~exp1","6.15.2-1~exp1","6.15.3-1~exp1","6.15.4-1~exp1","6.15.5-1~exp1","6.15.6-1~exp1","6.15~rc7-1~exp1","6.16-1~exp1","6.16.1-1~exp1","6.16.3-1~bpo13+1","6.16~rc7-1~exp1"]},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP4","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-288.0.0.191.oe2203sp4"}]}],"bundled":9},{"source":"osv","ecosystem":"openEuler:24.03-LTS","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-115.0.0.108.oe2403"}]}],"bundled":27},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP1","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-115.0.0.119.oe2403sp1"}]}],"bundled":27},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP2","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-115.0.0.121.oe2403sp2"}]}],"bundled":26},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP3","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-288.0.0.190.oe2203sp3"}]}],"bundled":11},{"source":"osv","ecosystem":"openEuler:20.03-LTS-SP4","package":"kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2511.2.0.0351.oe2003sp4"}]}],"bundled":27},{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"linux-hwe-edge","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.8.0-28.30~16.04.1","4.8.0-30.32~16.04.1","4.8.0-32.34~16.04.1","4.8.0-34.36~16.04.1","4.10.0-14.16~16.04.1","4.10.0-19.21~16.04.1","4.10.0-20.22~16.04.1","4.10.0-21.23~16.04.1","4.10.0-22.24~16.04.1","4.10.0-24.28~16.04.1","4.10.0-26.30~16.04.1","4.11.0-13.19~16.04.1","4.11.0-14.20~16.04.1","4.13.0-16.19~16.04.3","4.13.0-17.20~16.04.1","4.13.0-19.22~16.04.1","4.13.0-21.24~16.04.1","4.13.0-25.29~16.04.2","4.15.0-13.14~16.04.1","4.15.0-15.16~16.04.1","4.15.0-20.21~16.04.1","4.15.0-22.24~16.04.1","4.15.0-23.25~16.04.1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-aws-5.0","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.0.0-1021.24~18.04.1","5.0.0-1022.25~18.04.1","5.0.0-1023.26~18.04.1","5.0.0-1024.27~18.04.1","5.0.0-1025.28","5.0.0-1027.30"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-aws-5.3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1016.17~18.04.1","5.3.0-1017.18~18.04.1","5.3.0-1019.21~18.04.1","5.3.0-1023.25~18.04.1","5.3.0-1028.30~18.04.1","5.3.0-1030.32~18.04.1","5.3.0-1032.34~18.04.2","5.3.0-1033.35","5.3.0-1034.36","5.3.0-1035.37"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-azure","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.15.0-1002.2","4.15.0-1003.3","4.15.0-1004.4","4.15.0-1008.8","4.15.0-1009.9","4.15.0-1012.12","4.15.0-1013.13","4.15.0-1014.14","4.15.0-1018.18","4.15.0-1019.19","4.15.0-1021.21","4.15.0-1022.23","4.15.0-1023.24","4.15.0-1025.26","4.15.0-1028.29","4.15.0-1030.31","4.15.0-1031.32","4.15.0-1032.33","4.15.0-1035.36","4.15.0-1036.38","4.15.0-1037.39","4.18.0-1011.11~18.04.1","4.18.0-1013.13~18.04.1","4.18.0-1014.14~18.04.1","4.18.0-1018.18~18.04.1","4.18.0-1019.19~18.04.1","4.18.0-1020.20~18.04.1","4.18.0-1023.24~18.04.1","4.18.0-1024.25~18.04.1","4.18.0-1025.27~18.04.1","5.0.0-1014.14~18.04.1","5.0.0-1016.17~18.04.1","5.0.0-1018.19~18.04.1","5.0.0-1020.21~18.04.1","5.0.0-1022.23~18.04.1","5.0.0-1023.24~18.04.1","5.0.0-1025.27~18.04.1","5.0.0-1027.29~18.04.1","5.0.0-1028.30~18.04.1","5.0.0-1029.31~18.04.1","5.0.0-1031.33","5.0.0-1032.34","5.0.0-1035.37","5.0.0-1036.38"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-azure-5.3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1007.8~18.04.1","5.3.0-1008.9~18.04.1","5.3.0-1009.10~18.04.1","5.3.0-1010.11~18.04.1","5.3.0-1012.13~18.04.1","5.3.0-1013.14~18.04.1","5.3.0-1016.17~18.04.1","5.3.0-1018.19~18.04.1","5.3.0-1019.20~18.04.1","5.3.0-1020.21~18.04.1","5.3.0-1022.23~18.04.1","5.3.0-1028.29~18.04.1","5.3.0-1031.32~18.04.1","5.3.0-1032.33~18.04.1","5.3.0-1034.35~18.04.1","5.3.0-1035.36"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-azure-edge","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.18.0-1006.6~18.04.1","4.18.0-1007.7~18.04.1","4.18.0-1008.8~18.04.1","5.0.0-1012.12~18.04.2"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.15.0-1001.1","4.15.0-1003.3","4.15.0-1005.5","4.15.0-1006.6","4.15.0-1008.8","4.15.0-1009.9","4.15.0-1010.10","4.15.0-1014.14","4.15.0-1015.15","4.15.0-1017.18","4.15.0-1018.19","4.15.0-1019.20","4.15.0-1021.22","4.15.0-1023.24","4.15.0-1024.25","4.15.0-1025.26","4.15.0-1026.27","4.15.0-1027.28","4.15.0-1028.29","4.15.0-1029.31","4.15.0-1030.32","4.15.0-1032.34","4.15.0-1033.35","4.15.0-1034.36","4.15.0-1036.38","4.15.0-1037.39","4.15.0-1040.42","4.15.0-1042.45","4.15.0-1044.70","5.0.0-1020.20~18.04.1","5.0.0-1021.21~18.04.1","5.0.0-1025.26~18.04.1","5.0.0-1026.27~18.04.1","5.0.0-1028.29~18.04.1","5.0.0-1029.30~18.04.1","5.0.0-1031.32","5.0.0-1033.34","5.0.0-1034.35"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gcp-5.3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1008.9~18.04.1","5.3.0-1009.10~18.04.1","5.3.0-1010.11~18.04.1","5.3.0-1012.13~18.04.1","5.3.0-1014.15~18.04.1","5.3.0-1016.17~18.04.1","5.3.0-1017.18~18.04.1","5.3.0-1018.19~18.04.1","5.3.0-1020.22~18.04.1","5.3.0-1026.28~18.04.1","5.3.0-1029.31~18.04.1","5.3.0-1030.32~18.04.1","5.3.0-1032.34~18.04.1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gke-4.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.15.0-1030.32","4.15.0-1032.34","4.15.0-1033.35","4.15.0-1034.36","4.15.0-1036.38","4.15.0-1037.39","4.15.0-1040.42","4.15.0-1041.43","4.15.0-1042.44","4.15.0-1044.46","4.15.0-1045.48","4.15.0-1046.49","4.15.0-1048.51","4.15.0-1049.52","4.15.0-1050.53","4.15.0-1052.55","4.15.0-1055.58","4.15.0-1057.60","4.15.0-1058.61","4.15.0-1059.62","4.15.0-1063.66","4.15.0-1064.67","4.15.0-1066.69","4.15.0-1067.70","4.15.0-1069.72","4.15.0-1070.73","4.15.0-1072.76","4.15.0-1073.78","4.15.0-1074.79","4.15.0-1076.81","4.15.0-1077.82","4.15.0-1078.83","4.15.0-1079.84"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gke-5.4","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1025.25~18.04.1","5.4.0-1027.28~18.04.1","5.4.0-1029.31~18.04.1","5.4.0-1030.32~18.04.1","5.4.0-1032.34~18.04.1","5.4.0-1033.35~18.04.1","5.4.0-1035.37~18.04.1","5.4.0-1036.38~18.04.1","5.4.0-1037.39~18.04.1","5.4.0-1039.41~18.04.1","5.4.0-1040.42~18.04.1","5.4.0-1042.44~18.04.1","5.4.0-1043.45~18.04.1","5.4.0-1044.46~18.04.1","5.4.0-1046.48~18.04.1","5.4.0-1049.52~18.04.1","5.4.0-1051.54~18.04.1","5.4.0-1052.55~18.04.1","5.4.0-1053.56~18.04.1","5.4.0-1054.57~18.04.1","5.4.0-1055.58~18.04.1","5.4.0-1056.59~18.04.1","5.4.0-1057.60~18.04.1","5.4.0-1059.62~18.04.1","5.4.0-1061.64~18.04.1","5.4.0-1062.65~18.04.1","5.4.0-1063.66~18.04.1","5.4.0-1065.68~18.04.1","5.4.0-1066.69~18.04.1","5.4.0-1067.70~18.04.1","5.4.0-1068.71~18.04.1","5.4.0-1071.76~18.04.3","5.4.0-1072.77~18.04.1","5.4.0-1074.79~18.04.1","5.4.0-1076.82~18.04.1","5.4.0-1078.84~18.04.1","5.4.0-1080.86~18.04.1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-gkeop-5.4","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1001.1","5.4.0-1003.3","5.4.0-1004.5","5.4.0-1005.6","5.4.0-1007.8~18.04.1","5.4.0-1008.9~18.04.1","5.4.0-1009.10~18.04.1","5.4.0-1010.11~18.04.1","5.4.0-1011.12~18.04.2","5.4.0-1012.13~18.04.1","5.4.0-1013.14~18.04.1","5.4.0-1014.15~18.04.1","5.4.0-1015.16~18.04.1","5.4.0-1016.17~18.04.1","5.4.0-1018.19~18.04.1","5.4.0-1021.22~18.04.1","5.4.0-1022.23~18.04.1","5.4.0-1023.24~18.04.1","5.4.0-1024.25~18.04.1","5.4.0-1025.26~18.04.1","5.4.0-1026.27~18.04.1","5.4.0-1027.28~18.04.1","5.4.0-1029.30~18.04.2","5.4.0-1031.32~18.04.1","5.4.0-1032.33~18.04.1","5.4.0-1033.34~18.04.1","5.4.0-1034.35~18.04.1","5.4.0-1036.37~18.04.1","5.4.0-1037.38~18.04.1","5.4.0-1038.39~18.04.1","5.4.0-1039.40~18.04.1","5.4.0-1040.41~18.04.1","5.4.0-1043.44~18.04.1","5.4.0-1046.48~18.04.1","5.4.0-1048.51~18.04.1","5.4.0-1049.52~18.04.1","5.4.0-1051.54~18.04.1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-hwe","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.18.0-13.14~18.04.1","4.18.0-14.15~18.04.1","4.18.0-15.16~18.04.1","4.18.0-16.17~18.04.1","4.18.0-17.18~18.04.1","4.18.0-18.19~18.04.1","4.18.0-20.21~18.04.1","4.18.0-21.22~18.04.1","4.18.0-22.23~18.04.1","4.18.0-24.25~18.04.1","4.18.0-25.26~18.04.1","5.0.0-23.24~18.04.1","5.0.0-25.26~18.04.1","5.0.0-27.28~18.04.1","5.0.0-29.31~18.04.1","5.0.0-31.33~18.04.1","5.0.0-32.34~18.04.2","5.0.0-35.38~18.04.1","5.0.0-36.39~18.04.1","5.0.0-37.40~18.04.1","5.3.0-26.28~18.04.1","5.3.0-28.30~18.04.1","5.3.0-40.32~18.04.1","5.3.0-42.34~18.04.1","5.3.0-45.37~18.04.1","5.3.0-46.38~18.04.1","5.3.0-51.44~18.04.2","5.3.0-53.47~18.04.1","5.3.0-59.53~18.04.1","5.3.0-61.55~18.04.1","5.3.0-62.56~18.04.1","5.3.0-64.58~18.04.1","5.3.0-65.59","5.3.0-66.60","5.3.0-67.61","5.3.0-68.63","5.3.0-69.65","5.3.0-70.66","5.3.0-72.68","5.3.0-73.69","5.3.0-74.70","5.3.0-75.71","5.3.0-76.72"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-hwe-edge","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.0.0-15.16~18.04.1","5.0.0-16.17~18.04.1","5.0.0-17.18~18.04.1","5.0.0-19.20~18.04.1","5.0.0-20.21~18.04.1","5.3.0-19.20~18.04.2","5.3.0-22.24~18.04.1","5.3.0-23.25~18.04.1","5.3.0-23.25~18.04.2","5.3.0-24.26~18.04.2"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-oem","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.15.0-1002.3","4.15.0-1004.5","4.15.0-1006.9","4.15.0-1008.11","4.15.0-1009.12","4.15.0-1012.15","4.15.0-1013.16","4.15.0-1015.18","4.15.0-1017.20","4.15.0-1018.21","4.15.0-1021.24","4.15.0-1024.29","4.15.0-1026.31","4.15.0-1028.33","4.15.0-1030.35","4.15.0-1033.38","4.15.0-1034.39","4.15.0-1035.40","4.15.0-1036.41","4.15.0-1038.43","4.15.0-1039.44","4.15.0-1043.48","4.15.0-1045.50","4.15.0-1050.57","4.15.0-1056.65","4.15.0-1057.66","4.15.0-1059.68","4.15.0-1063.72","4.15.0-1064.73","4.15.0-1065.75","4.15.0-1066.76","4.15.0-1067.77","4.15.0-1069.79","4.15.0-1073.83","4.15.0-1076.86","4.15.0-1079.89","4.15.0-1080.90","4.15.0-1081.91","4.15.0-1087.97","4.15.0-1090.100","4.15.0-1091.101","4.15.0-1093.103","4.15.0-1094.104","4.15.0-1096.106","4.15.0-1097.107","4.15.0-1099.109","4.15.0-1100.110","4.15.0-1101.112","4.15.0-1102.113","4.15.0-1103.114"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-oracle-5.0","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.0.0-1007.12~18.04.1","5.0.0-1008.13~18.04.1","5.0.0-1009.14~18.04.1","5.0.0-1010.15~18.04.1","5.0.0-1011.16","5.0.0-1013.18","5.0.0-1014.19"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"linux-oracle-5.3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1011.12~18.04.1","5.3.0-1013.14~18.04.1","5.3.0-1014.15~18.04.1","5.3.0-1016.18~18.04.1","5.3.0-1018.20~18.04.1","5.3.0-1024.26~18.04.1","5.3.0-1027.29~18.04.1","5.3.0-1028.30~18.04.1","5.3.0-1030.32~18.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-aws-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1009.9~20.04.2","5.11.0-1014.15~20.04.1","5.11.0-1016.17~20.04.1","5.11.0-1017.18~20.04.1","5.11.0-1019.20~20.04.1","5.11.0-1020.21~20.04.2","5.11.0-1021.22~20.04.2","5.11.0-1022.23~20.04.1","5.11.0-1023.24~20.04.1","5.11.0-1025.27~20.04.1","5.11.0-1027.30~20.04.1","5.11.0-1028.31~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-aws-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1008.9~20.04.2","5.13.0-1011.12~20.04.1","5.13.0-1012.13~20.04.1","5.13.0-1014.15~20.04.1","5.13.0-1017.19~20.04.1","5.13.0-1019.21~20.04.1","5.13.0-1021.23~20.04.2","5.13.0-1022.24~20.04.1","5.13.0-1023.25~20.04.1","5.13.0-1025.27~20.04.1","5.13.0-1028.31~20.04.1","5.13.0-1029.32~20.04.1","5.13.0-1031.35~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-aws-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-1035.37~20.04.1","5.8.0-1038.40~20.04.1","5.8.0-1041.43~20.04.1","5.8.0-1042.44~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1007.7~20.04.2","5.11.0-1012.13~20.04.1","5.11.0-1013.14~20.04.1","5.11.0-1015.16~20.04.1","5.11.0-1017.18~20.04.1","5.11.0-1019.20~20.04.1","5.11.0-1020.21~20.04.1","5.11.0-1021.22~20.04.1","5.11.0-1022.23~20.04.1","5.11.0-1023.24~20.04.1","5.11.0-1025.27~20.04.1","5.11.0-1027.30~20.04.1","5.11.0-1028.31~20.04.2"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1009.10~20.04.2","5.13.0-1012.14~20.04.1","5.13.0-1013.15~20.04.1","5.13.0-1014.16~20.04.1","5.13.0-1017.19~20.04.1","5.13.0-1021.24~20.04.1","5.13.0-1022.26~20.04.1","5.13.0-1023.27~20.04.1","5.13.0-1025.29~20.04.1","5.13.0-1028.33~20.04.1","5.13.0-1029.34~20.04.1","5.13.0-1031.37~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-1033.35~20.04.1","5.8.0-1036.38~20.04.1","5.8.0-1039.42~20.04.1","5.8.0-1040.43~20.04.1","5.8.0-1041.44~20.04.1","5.8.0-1042.45~20.04.1","5.8.0-1043.46~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-azure-fde","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1063.66+cvm2.2","5.4.0-1063.66+cvm3.2","5.4.0-1064.67+cvm1.1","5.4.0-1065.68+cvm2.1","5.4.0-1067.70+cvm1.1","5.4.0-1068.71+cvm1.1","5.4.0-1069.72+cvm1.1","5.4.0-1070.73+cvm1.1","5.4.0-1072.75+cvm1.1","5.4.0-1073.76+cvm1.1","5.4.0-1074.77+cvm1.1","5.4.0-1076.79+cvm1.1","5.4.0-1078.81+cvm1.1","5.4.0-1080.83+cvm1.1","5.4.0-1083.87+cvm1.1","5.4.0-1085.90+cvm1.1","5.4.0-1085.90+cvm2.1","5.4.0-1086.91+cvm1.1","5.4.0-1089.94+cvm1.2","5.4.0-1090.95+cvm1.1","5.4.0-1091.96+cvm1.1","5.4.0-1092.97+cvm1.1","5.4.0-1095.101+cvm1.1","5.4.0-1098.104+cvm1.1","5.4.0-1100.106+cvm1.1","5.4.0-1103.109+cvm1.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gcp-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1009.10~20.04.1","5.11.0-1014.16~20.04.1","5.11.0-1017.19~20.04.1","5.11.0-1018.20~20.04.2","5.11.0-1020.22~20.04.1","5.11.0-1021.23~20.04.1","5.11.0-1022.24~20.04.1","5.11.0-1023.25~20.04.1","5.11.0-1024.26~20.04.1","5.11.0-1026.29~20.04.1","5.11.0-1028.32~20.04.1","5.11.0-1029.33~20.04.3"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gcp-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1008.9~20.04.3","5.13.0-1012.15~20.04.1","5.13.0-1013.16~20.04.1","5.13.0-1015.18~20.04.1","5.13.0-1019.23~20.04.1","5.13.0-1021.25~20.04.1","5.13.0-1023.28~20.04.1","5.13.0-1024.29~20.04.1","5.13.0-1025.30~20.04.1","5.13.0-1027.32~20.04.1","5.13.0-1030.36~20.04.1","5.13.0-1031.37~20.04.1","5.13.0-1033.40~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gcp-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-1032.34~20.04.1","5.8.0-1035.37~20.04.1","5.8.0-1038.40~20.04.1","5.8.0-1039.41"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gke","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1033.35","5.4.0-1035.37","5.4.0-1036.38","5.4.0-1037.39","5.4.0-1039.41","5.4.0-1041.43","5.4.0-1042.44","5.4.0-1043.45","5.4.0-1044.46","5.4.0-1046.48","5.4.0-1049.52","5.4.0-1051.54","5.4.0-1052.55","5.4.0-1053.56","5.4.0-1054.57","5.4.0-1055.58","5.4.0-1056.59","5.4.0-1057.60","5.4.0-1059.62","5.4.0-1061.64","5.4.0-1062.65","5.4.0-1063.66","5.4.0-1065.68","5.4.0-1066.69","5.4.0-1067.70","5.4.0-1068.71","5.4.0-1071.76","5.4.0-1072.77","5.4.0-1074.79","5.4.0-1076.82","5.4.0-1078.84","5.4.0-1080.86","5.4.0-1081.87","5.4.0-1083.89","5.4.0-1084.90","5.4.0-1086.93","5.4.0-1087.94","5.4.0-1090.97","5.4.0-1091.98","5.4.0-1094.101","5.4.0-1095.102","5.4.0-1096.103","5.4.0-1097.104","5.4.0-1098.105","5.4.0-1099.106","5.4.0-1100.107","5.4.0-1101.108","5.4.0-1102.109","5.4.0-1103.110","5.4.0-1104.111","5.4.0-1105.112"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gke-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1011.14~20.04.1","5.15.0-1014.17~20.04.1","5.15.0-1015.18~20.04.1","5.15.0-1016.19~20.04.1","5.15.0-1019.23~20.04.1","5.15.0-1020.25~20.04.1","5.15.0-1023.28~20.04.2","5.15.0-1027.32~20.04.1","5.15.0-1028.33~20.04.1","5.15.0-1029.34~20.04.1","5.15.0-1031.36~20.04.1","5.15.0-1032.37~20.04.1","5.15.0-1033.38~20.04.1","5.15.0-1034.39~20.04.1","5.15.0-1036.41~20.04.1","5.15.0-1037.42~20.04.1","5.15.0-1038.43~20.04.1","5.15.0-1039.44~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gkeop","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-1008.9","5.4.0-1009.10","5.4.0-1010.11","5.4.0-1011.12","5.4.0-1012.13","5.4.0-1013.14","5.4.0-1014.15","5.4.0-1015.16","5.4.0-1016.17","5.4.0-1018.19","5.4.0-1021.22","5.4.0-1022.23","5.4.0-1023.24","5.4.0-1024.25","5.4.0-1025.26","5.4.0-1026.27","5.4.0-1027.28","5.4.0-1029.30","5.4.0-1031.32","5.4.0-1032.33","5.4.0-1033.34","5.4.0-1034.35","5.4.0-1036.37","5.4.0-1037.38","5.4.0-1038.39","5.4.0-1039.40","5.4.0-1040.41","5.4.0-1043.44","5.4.0-1046.48","5.4.0-1048.51","5.4.0-1049.52","5.4.0-1051.54","5.4.0-1052.55","5.4.0-1053.56","5.4.0-1054.57","5.4.0-1056.60","5.4.0-1057.61","5.4.0-1060.64","5.4.0-1061.65","5.4.0-1062.66","5.4.0-1064.68","5.4.0-1065.69","5.4.0-1066.70","5.4.0-1067.71","5.4.0-1068.72","5.4.0-1069.73","5.4.0-1070.74","5.4.0-1071.75","5.4.0-1072.76","5.4.0-1073.77","5.4.0-1074.78","5.4.0-1075.79","5.4.0-1076.80","5.4.0-1077.81","5.4.0-1078.82","5.4.0-1079.83","5.4.0-1080.84","5.4.0-1081.85","5.4.0-1083.87","5.4.0-1084.88","5.4.0-1085.89","5.4.0-1086.90","5.4.0-1087.91","5.4.0-1088.92","5.4.0-1089.93","5.4.0-1090.94","5.4.0-1091.95","5.4.0-1092.96","5.4.0-1093.97","5.4.0-1094.98","5.4.0-1095.99","5.4.0-1096.100","5.4.0-1097.101","5.4.0-1098.102","5.4.0-1099.103","5.4.0-1100.104","5.4.0-1101.105","5.4.0-1102.106"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-gkeop-5.15","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1003.5~20.04.2","5.15.0-1005.7~20.04.1","5.15.0-1007.10~20.04.1","5.15.0-1008.12~20.04.1","5.15.0-1011.15~20.04.2","5.15.0-1012.16~20.04.1","5.15.0-1013.17~20.04.1","5.15.0-1015.19~20.04.1","5.15.0-1016.21~20.04.1","5.15.0-1017.22~20.04.1","5.15.0-1018.23~20.04.1","5.15.0-1019.24~20.04.1","5.15.0-1020.25~20.04.1","5.15.0-1021.26~20.04.1","5.15.0-1022.27~20.04.1","5.15.0-1023.28~20.04.1","5.15.0-1024.29~20.04.1","5.15.0-1025.30~20.04.1","5.15.0-1026.31~20.04.1","5.15.0-1027.32~20.04.1","5.15.0-1028.33~20.04.1","5.15.0-1030.35~20.04.1","5.15.0-1031.37~20.04.1","5.15.0-1032.38~20.04.1","5.15.0-1033.39~20.04.1","5.15.0-1034.40~20.04.1","5.15.0-1035.41~20.04.1","5.15.0-1036.42~20.04.1","5.15.0-1037.43~20.04.1","5.15.0-1038.44~20.04.1","5.15.0-1039.45~20.04.1","5.15.0-1040.46~20.04.1","5.15.0-1043.50~20.04.1","5.15.0-1044.51~20.04.1","5.15.0-1045.52~20.04.1","5.15.0-1046.53~20.04.1","5.15.0-1047.54~20.04.1","5.15.0-1048.55~20.04.1","5.15.0-1049.56~20.04.1","5.15.0-1050.57~20.04.1","5.15.0-1051.58~20.04.1","5.15.0-1052.59~20.04.1","5.15.0-1053.60~20.04.1","5.15.0-1054.61~20.04.1","5.15.0-1055.62~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-hwe-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-22.23~20.04.1","5.11.0-25.27~20.04.1","5.11.0-27.29~20.04.1","5.11.0-34.36~20.04.1","5.11.0-36.40~20.04.1","5.11.0-37.41~20.04.2","5.11.0-38.42~20.04.1","5.11.0-40.44~20.04.2","5.11.0-41.45~20.04.1","5.11.0-43.47~20.04.2","5.11.0-44.48~20.04.2","5.11.0-46.51~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-hwe-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-21.21~20.04.1","5.13.0-22.22~20.04.1","5.13.0-23.23~20.04.2","5.13.0-25.26~20.04.1","5.13.0-27.29~20.04.1","5.13.0-28.31~20.04.1","5.13.0-30.33~20.04.1","5.13.0-35.40~20.04.1","5.13.0-37.42~20.04.1","5.13.0-39.44~20.04.1","5.13.0-40.45~20.04.1","5.13.0-41.46~20.04.1","5.13.0-44.49~20.04.1","5.13.0-48.54~20.04.1","5.13.0-51.58~20.04.1","5.13.0-52.59~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-hwe-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-23.24~20.04.1","5.8.0-25.26~20.04.1","5.8.0-28.30~20.04.1","5.8.0-29.31~20.04.1","5.8.0-31.33~20.04.1","5.8.0-33.36~20.04.1","5.8.0-34.37~20.04.2","5.8.0-36.40~20.04.1","5.8.0-38.43~20.04.1","5.8.0-40.45~20.04.1","5.8.0-41.46~20.04.1","5.8.0-43.49~20.04.1","5.8.0-44.50~20.04.1","5.8.0-45.51~20.04.1","5.8.0-48.54~20.04.1","5.8.0-49.55~20.04.1","5.8.0-50.56~20.04.1","5.8.0-53.60~20.04.1","5.8.0-55.62~20.04.1","5.8.0-59.66~20.04.1","5.8.0-63.71~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-intel-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1007.7","5.13.0-1008.8","5.13.0-1009.9","5.13.0-1010.10","5.13.0-1011.11","5.13.0-1014.15","5.13.0-1017.19"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oem-5.10","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.10.0-1008.9","5.10.0-1011.12","5.10.0-1013.14","5.10.0-1014.15","5.10.0-1016.17","5.10.0-1017.18","5.10.0-1019.20","5.10.0-1021.22","5.10.0-1022.23","5.10.0-1023.24","5.10.0-1025.26","5.10.0-1026.27","5.10.0-1029.30","5.10.0-1032.33","5.10.0-1033.34","5.10.0-1034.35","5.10.0-1038.40","5.10.0-1044.46","5.10.0-1045.47","5.10.0-1049.51","5.10.0-1050.52","5.10.0-1051.53","5.10.0-1052.54","5.10.0-1053.55","5.10.0-1055.58","5.10.0-1057.61"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oem-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1009.10","5.13.0-1010.11","5.13.0-1012.16","5.13.0-1014.18","5.13.0-1017.21","5.13.0-1019.23","5.13.0-1020.24","5.13.0-1021.25","5.13.0-1022.26","5.13.0-1026.32","5.13.0-1028.35","5.13.0-1029.36"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oem-5.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.14.0-1004.4","5.14.0-1005.5","5.14.0-1007.7","5.14.0-1008.8","5.14.0-1010.10","5.14.0-1011.11","5.14.0-1013.13","5.14.0-1018.19","5.14.0-1020.22","5.14.0-1022.24","5.14.0-1024.26","5.14.0-1027.30","5.14.0-1029.32","5.14.0-1031.34","5.14.0-1032.35","5.14.0-1033.36","5.14.0-1034.37","5.14.0-1036.40","5.14.0-1038.42","5.14.0-1042.47","5.14.0-1044.49","5.14.0-1045.51","5.14.0-1046.53","5.14.0-1047.54","5.14.0-1048.55","5.14.0-1049.56","5.14.0-1050.57","5.14.0-1051.58","5.14.0-1052.59","5.14.0-1054.61","5.14.0-1055.62","5.14.0-1056.63","5.14.0-1057.64","5.14.0-1058.66","5.14.0-1059.67"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oem-5.6","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.6.0-1007.7","5.6.0-1008.8","5.6.0-1010.10","5.6.0-1011.11","5.6.0-1013.13","5.6.0-1017.17","5.6.0-1018.18","5.6.0-1020.20","5.6.0-1021.21","5.6.0-1023.23","5.6.0-1026.26","5.6.0-1027.27","5.6.0-1028.28","5.6.0-1031.32","5.6.0-1032.33","5.6.0-1033.35","5.6.0-1034.36","5.6.0-1035.37","5.6.0-1036.39","5.6.0-1039.43","5.6.0-1042.46","5.6.0-1047.51","5.6.0-1048.52","5.6.0-1050.54","5.6.0-1052.56","5.6.0-1053.57","5.6.0-1054.58","5.6.0-1055.59","5.6.0-1056.60"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oracle-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1008.8~20.04.1","5.11.0-1013.14~20.04.1","5.11.0-1016.17~20.04.1","5.11.0-1017.18~20.04.1","5.11.0-1019.20~20.04.1","5.11.0-1020.21~20.04.1","5.11.0-1021.22~20.04.1","5.11.0-1022.23~20.04.1","5.11.0-1023.24~20.04.1","5.11.0-1025.27~20.04.1","5.11.0-1027.30~20.04.1","5.11.0-1028.31~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oracle-5.13","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.13.0-1011.13~20.04.2","5.13.0-1015.19~20.04.1","5.13.0-1016.20~20.04.1","5.13.0-1018.22~20.04.1","5.13.0-1021.26~20.04.1","5.13.0-1025.30~20.04.1","5.13.0-1027.32~20.04.1","5.13.0-1028.33~20.04.1","5.13.0-1030.35~20.04.1","5.13.0-1033.39~20.04.1","5.13.0-1034.40~20.04.1","5.13.0-1036.43~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-oracle-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-1031.32~20.04.2","5.8.0-1033.34~20.04.1","5.8.0-1034.35~20.04.2","5.8.0-1037.38~20.04.1","5.8.0-1038.39~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-raspi2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1007.8","5.3.0-1014.16","5.3.0-1015.17","5.3.0-1017.19","5.4.0-1004.4","5.4.0-1006.6"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-riscv","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.4.0-24.28","5.4.0-26.30","5.4.0-27.31","5.4.0-28.32","5.4.0-30.34","5.4.0-31.35","5.4.0-33.37","5.4.0-34.38","5.4.0-36.41","5.4.0-37.42","5.4.0-39.44","5.4.0-40.45"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-riscv-5.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.11.0-1015.16~20.04.1","5.11.0-1017.18~20.04.1","5.11.0-1018.19~20.04.2","5.11.0-1020.21~20.04.1","5.11.0-1021.22~20.04.1","5.11.0-1022.23~20.04.1","5.11.0-1023.24~20.04.1","5.11.0-1024.25~20.04.1","5.11.0-1026.28~20.04.1","5.11.0-1028.31~20.04.1","5.11.0-1029.32~20.04.1","5.11.0-1030.34","5.11.0-1031.35"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"linux-riscv-5.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.8.0-14.16~20.04.1","5.8.0-14.16~20.04.3","5.8.0-16.18~20.04.1","5.8.0-17.19~20.04.1","5.8.0-18.20~20.04.1","5.8.0-20.22~20.04.1","5.8.0-22.24~20.04.1","5.8.0-25.27~20.04.1","5.8.0-26.28~20.04.1","5.8.0-29.31~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-allwinner-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1007.7~22.04.1","5.19.0-1009.9~22.04.1","5.19.0-1010.10~22.04.1","5.19.0-1011.11~22.04.1","5.19.0-1012.12~22.04.1","5.19.0-1013.13~22.04.1","5.19.0-1014.14~22.04.1","5.19.0-1015.15~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1019.20~22.04.1","5.19.0-1020.21~22.04.1","5.19.0-1022.23~22.04.1","5.19.0-1023.24~22.04.1","5.19.0-1024.25~22.04.1","5.19.0-1025.26~22.04.1","5.19.0-1026.27~22.04.1","5.19.0-1027.28~22.04.1","5.19.0-1028.29~22.04.1","5.19.0-1029.30~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1005.5~22.04.1","6.2.0-1006.6~22.04.1","6.2.0-1007.7~22.04.1","6.2.0-1008.8~22.04.1","6.2.0-1009.9~22.04.3","6.2.0-1010.10~22.04.1","6.2.0-1011.11~22.04.1","6.2.0-1012.12~22.04.1","6.2.0-1013.13~22.04.1","6.2.0-1014.14~22.04.1","6.2.0-1015.15~22.04.1","6.2.0-1016.16~22.04.1","6.2.0-1017.17~22.04.1","6.2.0-1018.18~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-aws-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1008.8~22.04.1","6.5.0-1010.10~22.04.1","6.5.0-1011.11~22.04.1","6.5.0-1012.12~22.04.1","6.5.0-1014.14~22.04.1","6.5.0-1015.15~22.04.1","6.5.0-1016.16~22.04.1","6.5.0-1017.17~22.04.2","6.5.0-1018.18~22.04.1","6.5.0-1020.20~22.04.1","6.5.0-1021.21~22.04.1","6.5.0-1022.22~22.04.1","6.5.0-1023.23~22.04.1","6.5.0-1024.24~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-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-fde-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1025.28~22.04.1.1","5.19.0-1026.29~22.04.1.1","5.19.0-1027.30~22.04.2.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-azure-fde-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1008.8~22.04.1.1","6.2.0-1009.9~22.04.3.1","6.2.0-1011.11~22.04.1.1","6.2.0-1012.12~22.04.1.1","6.2.0-1014.14~22.04.1.1","6.2.0-1015.15~22.04.1.1","6.2.0-1016.16~22.04.1.1","6.2.0-1017.17~22.04.1.1","6.2.0-1018.18~22.04.1.1","6.2.0-1019.19~22.04.1.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1020.22~22.04.2","5.19.0-1021.23~22.04.1","5.19.0-1022.24~22.04.1","5.19.0-1024.26~22.04.1","5.19.0-1025.27~22.04.1","5.19.0-1026.28~22.04.1","5.19.0-1027.29~22.04.1","5.19.0-1030.32~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1009.9~22.04.3","6.2.0-1010.10~22.04.1","6.2.0-1011.11~22.04.1","6.2.0-1011.11~22.04.3","6.2.0-1012.12~22.04.1","6.2.0-1013.13~22.04.1","6.2.0-1014.14~22.04.1","6.2.0-1016.18~22.04.1","6.2.0-1017.19~22.04.1","6.2.0-1018.20~22.04.1","6.2.0-1019.21~22.04.1","6.2.0-1021.23~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-gcp-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1010.10~22.04.3","6.5.0-1011.11~22.04.1","6.5.0-1013.13~22.04.1","6.5.0-1014.14~22.04.1","6.5.0-1015.15~22.04.1","6.5.0-1016.16~22.04.1","6.5.0-1017.17~22.04.1","6.5.0-1018.18~22.04.1","6.5.0-1020.20~22.04.1","6.5.0-1022.24~22.04.1","6.5.0-1023.25~22.04.1","6.5.0-1024.26~22.04.1","6.5.0-1025.27~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-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-intel-iot-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.15.0-1073.75"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-5.19","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.19.0-1017.18~22.04.1","5.19.0-1018.19~22.04.1","5.19.0-1021.22~22.04.1","5.19.0-1022.23~22.04.1","5.19.0-1023.24~22.04.1","5.19.0-1024.25~22.04.1","5.19.0-1025.26~22.04.1","5.19.0-1027.28~22.04.1","5.19.0-1028.29~22.04.1","5.19.0-1030.30"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-6.2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.0-1008.8~22.04.1","6.2.0-1009.9~22.04.1","6.2.0-1011.11~22.04.1","6.2.0-1012.12~22.04.1","6.2.0-1013.13~22.04.1","6.2.0-1014.14~22.04.1","6.2.0-1015.15~22.04.1","6.2.0-1016.16~22.04.1","6.2.0-1017.17~22.04.1","6.2.0-1018.18~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-lowlatency-hwe-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-14.14.1~22.04.1","6.5.0-15.15.1.1~22.04.1","6.5.0-17.17.1.1.1~22.04.1","6.5.0-21.21.1~22.04.1","6.5.0-25.25.1~22.04.1","6.5.0-26.26.1~22.04.1","6.5.0-27.28.1~22.04.1","6.5.0-28.29.1~22.04.1","6.5.0-35.35.1~22.04.1","6.5.0-41.41.1~22.04.1","6.5.0-42.42.1~22.04.1","6.5.0-44.44.1~22.04.1","6.5.0-45.45.1~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-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-oem-5.17","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.17.0-1003.3","5.17.0-1004.4","5.17.0-1006.6","5.17.0-1011.12","5.17.0-1012.13","5.17.0-1013.14","5.17.0-1014.15","5.17.0-1015.16","5.17.0-1016.17","5.17.0-1017.18","5.17.0-1018.19","5.17.0-1019.20","5.17.0-1020.21","5.17.0-1021.22","5.17.0-1024.25","5.17.0-1025.26","5.17.0-1026.27","5.17.0-1027.28","5.17.0-1028.29","5.17.0-1029.30","5.17.0-1030.31","5.17.0-1031.32","5.17.0-1032.33","5.17.0-1033.34","5.17.0-1034.35","5.17.0-1035.36"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oem-6.0","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.0.0-1006.6","6.0.0-1007.7","6.0.0-1008.8","6.0.0-1009.9","6.0.0-1010.10","6.0.0-1011.11","6.0.0-1012.12","6.0.0-1013.13","6.0.0-1014.14","6.0.0-1015.15","6.0.0-1016.16","6.0.0-1017.17","6.0.0-1018.18","6.0.0-1019.19","6.0.0-1020.20","6.0.0-1021.21"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oem-6.1","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.1.0-1004.4","6.1.0-1006.6","6.1.0-1007.7","6.1.0-1008.8","6.1.0-1009.9","6.1.0-1010.10","6.1.0-1012.12","6.1.0-1013.13","6.1.0-1014.14","6.1.0-1015.15","6.1.0-1016.16","6.1.0-1017.17","6.1.0-1019.19","6.1.0-1020.20","6.1.0-1021.21","6.1.0-1022.22","6.1.0-1023.23","6.1.0-1024.24","6.1.0-1025.25","6.1.0-1026.26","6.1.0-1027.27","6.1.0-1028.28","6.1.0-1029.29","6.1.0-1033.33","6.1.0-1034.34","6.1.0-1035.35","6.1.0-1036.36"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oem-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1003.3","6.5.0-1004.4","6.5.0-1006.6","6.5.0-1007.7","6.5.0-1008.8","6.5.0-1009.10","6.5.0-1011.12","6.5.0-1013.14","6.5.0-1014.15","6.5.0-1015.16","6.5.0-1016.17","6.5.0-1018.19","6.5.0-1019.20","6.5.0-1020.21","6.5.0-1022.23","6.5.0-1023.24","6.5.0-1024.25","6.5.0-1025.26","6.5.0-1027.28"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-oracle-6.5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-1013.13~22.04.4","6.5.0-1014.14~22.04.1","6.5.0-1015.15~22.04.1","6.5.0-1016.16~22.04.1","6.5.0-1018.18~22.04.1","6.5.0-1019.19~22.04.1","6.5.0-1020.20~22.04.1","6.5.0-1021.21~22.04.1","6.5.0-1023.23~22.04.1","6.5.0-1024.24~22.04.1","6.5.0-1025.25~22.04.1","6.5.0-1026.26~22.04.1","6.5.0-1027.27~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"linux-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-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:24.04:LTS","package":"linux-aws-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1017.17~24.04.1"}]}],"versions":["6.14.0-1007.7~24.04.1","6.14.0-1009.9~24.04.1","6.14.0-1010.10~24.04.1","6.14.0-1011.11~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1013.13~24.04.1","6.14.0-1014.14~24.04.1","6.14.0-1015.15~24.04.1","6.14.0-1016.16~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure-6.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.11.0-1008.8~24.04.1","6.11.0-1012.12~24.04.1","6.11.0-1013.13~24.04.1","6.11.0-1014.14~24.04.1","6.11.0-1015.15~24.04.1","6.11.0-1017.17~24.04.1","6.11.0-1018.18~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1017.17~24.04.1"}]}],"versions":["6.14.0-1010.10~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1013.13~24.04.1","6.14.0-1014.14~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure-fde-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.14.0-1012.12~24.04.1","6.14.0-1013.13~24.04.1","6.14.0-1014.14~24.04.1","6.14.0-1015.15~24.04.1","6.14.0-1017.17~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure-nvidia-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.14.0-1003.3","6.14.0-1006.6","6.14.0-1007.7"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp-6.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.11.0-1006.6~24.04.2","6.11.0-1011.11~24.04.1","6.11.0-1013.13~24.04.1","6.11.0-1014.14~24.04.1","6.11.0-1015.15~24.04.1","6.11.0-1016.16~24.04.1","6.11.0-1017.17~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1020.21~24.04.1"}]}],"versions":["6.14.0-1007.7~24.04.1","6.14.0-1011.11~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1014.15~24.04.1","6.14.0-1015.16~24.04.1","6.14.0-1016.17~24.04.1","6.14.0-1017.18~24.04.1","6.14.0-1018.19~24.04.1","6.14.0-1019.20~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-hwe-6.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.11.0-17.17~24.04.2","6.11.0-19.19~24.04.1","6.11.0-21.21~24.04.1","6.11.0-24.24~24.04.1","6.11.0-25.25~24.04.1","6.11.0-26.26~24.04.1","6.11.0-28.28~24.04.1","6.11.0-29.29~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-intel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.8.0-1005.12","6.8.0-1006.13","6.8.0-1007.14"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-lowlatency-hwe-6.11","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.11.0-1009.10~24.04.1","6.11.0-1011.12~24.04.1","6.11.0-1012.13~24.04.1","6.11.0-1013.14~24.04.1","6.11.0-1014.15~24.04.1","6.11.0-1015.16~24.04.2","6.11.0-1016.17~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1016.16"}]}],"versions":["6.14.0-1004.4","6.14.0-1005.5","6.14.0-1006.6","6.14.0-1007.7","6.14.0-1008.8","6.14.0-1010.10","6.14.0-1011.11","6.14.0-1012.12","6.14.0-1013.13","6.14.0-1014.14","6.14.0-1015.15"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.8","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.8.0-1003.3","6.8.0-1004.4","6.8.0-1005.5","6.8.0-1006.6","6.8.0-1007.7","6.8.0-1008.8","6.8.0-1009.9","6.8.0-1010.10","6.8.0-1011.11","6.8.0-1012.12","6.8.0-1013.13","6.8.0-1014.14","6.8.0-1016.16","6.8.0-1017.17","6.8.0-1018.18","6.8.0-1019.19","6.8.0-1020.20","6.8.0-1024.24","6.8.0-1025.25","6.8.0-1026.26","6.8.0-1027.27","6.8.0-1028.28","6.8.0-1029.29","6.8.0-1030.30","6.8.0-1031.31","6.8.0-1032.32"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oracle-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1017.17~24.04.1"}]}],"versions":["6.14.0-1007.7~24.04.1","6.14.0-1009.9~24.04.1","6.14.0-1010.10~24.04.1","6.14.0-1011.11~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1013.13~24.04.1","6.14.0-1014.14~24.04.1","6.14.0-1015.15~24.04.1","6.14.0-1016.16~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-raspi-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.8.0-2019.20"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-realtime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.8.1-1015.16"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-riscv","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.5.0-9.9.1","6.8.0-20.20.1","6.8.0-28.28.1","6.8.0-31.31.1","6.8.0-35.35.1","6.8.0-36.36.1","6.8.0-38.38.1","6.8.0-39.39.1","6.8.0-40.40.1","6.8.0-41.41.1","6.8.0-44.44.1","6.8.0-47.47.1","6.8.0-48.48.1","6.8.0-49.49.1","6.8.0-50.51.1","6.8.0-51.52.1","6.8.0-52.53.1","6.8.0-53.55.1","6.8.0-55.57.1","6.8.0-56.58.1","6.8.0-57.59.1","6.8.0-58.60.1","6.8.0-59.61.1","6.8.0-60.63.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-riscv-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-36.36.1~24.04.1"}]}],"versions":["6.14.0-22.22.1~24.04.1","6.14.0-23.23.1~24.04.1","6.14.0-24.24.1~24.04.1","6.14.0-27.27.1~24.04.1","6.14.0-28.28.1~24.04.1","6.14.0-29.29.1~24.04.1","6.14.0-32.32.1~24.04.1","6.14.0-33.33.1~24.04.1","6.14.0-34.34.1~24.04.1","6.14.0-35.35.1~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-realtime-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1016.16~24.04.1"}]}],"versions":["6.14.0-1003.3~24.04.3","6.14.0-1010.10~24.04.1","6.14.0-1011.11~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1013.13~24.04.1","6.14.0-1014.14~24.04.1","6.14.0-1015.15~24.04.1"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"linux-azure-fde","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.17.0-1003.3","6.17.0-1004.4","6.17.0-1005.5","6.17.0-1007.7","6.17.0-1008.8","6.17.0-1010.10","6.17.0-1012.12","6.17.0-1014.14","6.17.0-1015.15","6.17.0-1017.17"]},{"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-hwe-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-36.36~24.04.1"}]}],"versions":["6.14.0-24.24~24.04.3","6.14.0-27.27~24.04.1","6.14.0-28.28~24.04.1","6.14.0-29.29~24.04.1","6.14.0-32.32~24.04.1","6.14.0-33.33~24.04.1","6.14.0-34.34~24.04.1","6.14.0-35.35~24.04.1"],"bundled":200},{"source":"osv","ecosystem":"Ubuntu:Pro:Realtime:24.04:LTS","package":"linux-realtime-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1016.16~24.04.1"}]}],"versions":["6.14.0-1003.3~24.04.3","6.14.0-1010.10~24.04.1","6.14.0-1011.11~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1013.13~24.04.1","6.14.0-1014.14~24.04.1","6.14.0-1015.15~24.04.1"],"bundled":200},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-aws-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1017.17~24.04.1"}]}],"versions":["6.14.0-1007.7~24.04.1","6.14.0-1009.9~24.04.1","6.14.0-1010.10~24.04.1","6.14.0-1011.11~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1013.13~24.04.1","6.14.0-1014.14~24.04.1","6.14.0-1015.15~24.04.1","6.14.0-1016.16~24.04.1"],"bundled":200},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oracle-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1017.17~24.04.1"}]}],"versions":["6.14.0-1007.7~24.04.1","6.14.0-1009.9~24.04.1","6.14.0-1010.10~24.04.1","6.14.0-1011.11~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1013.13~24.04.1","6.14.0-1014.14~24.04.1","6.14.0-1015.15~24.04.1","6.14.0-1016.16~24.04.1"],"bundled":200},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-gcp-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1020.21~24.04.1"}]}],"versions":["6.14.0-1007.7~24.04.1","6.14.0-1011.11~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1014.15~24.04.1","6.14.0-1015.16~24.04.1","6.14.0-1016.17~24.04.1","6.14.0-1017.18~24.04.1","6.14.0-1018.19~24.04.1","6.14.0-1019.20~24.04.1"],"bundled":200},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-oem-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1016.16"}]}],"versions":["6.14.0-1004.4","6.14.0-1005.5","6.14.0-1006.6","6.14.0-1007.7","6.14.0-1008.8","6.14.0-1010.10","6.14.0-1011.11","6.14.0-1012.12","6.14.0-1013.13","6.14.0-1014.14","6.14.0-1015.15"],"bundled":197},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"linux-azure-6.14","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.14.0-1017.17~24.04.1"}]}],"versions":["6.14.0-1010.10~24.04.1","6.14.0-1012.12~24.04.1","6.14.0-1013.13~24.04.1","6.14.0-1014.14~24.04.1"],"bundled":205}],"products":[{"vendor":"linux","product":"linux"},{"vendor":"linux","product":"linux_kernel"}],"references":[{"url":"https://git.kernel.org/stable/c/656eaddbc952e1baae2f69281c22debe22140312","tags":["Patch","web","report"]},{"url":"https://git.kernel.org/stable/c/c1101113d45838a823188ae25c61af97552a28ae","tags":["Patch","web","report"]},{"url":"https://git.kernel.org/stable/c/9f1e8cd0b7c4c944e9921b52a6661b5eda2705ab","tags":["Patch","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39725","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-qmpx-wcm9-r94f"},{"url":"https://docs.bell-sw.com/security/cves/CVE-2025-39725","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/39xxx/CVE-2025-39725.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-2025-39725","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2632","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53174","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57929","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39973","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39993","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40021","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40042","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40044","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40081","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2633","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21991","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22093","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37998","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39685","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39701","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39742","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39782","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39832","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39847","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39860","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39880","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39889","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39945","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39949","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39969","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39970","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39972","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39977","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40006","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40057","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40071","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40102","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2634","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2635","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2636","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53622","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53726","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2659","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50349","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50352","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50435","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50482","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50484","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50489","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50520","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50531","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50551","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50552","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53185","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53199","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53344","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53427","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53446","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53454","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53500","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53582","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53641","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53675","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53676","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53717","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53733","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2025-39725","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-39725","tags":["report"]},{"url":"https://git.kernel.org/linus/9f1e8cd0b7c4c944e9921b52a6661b5eda2705ab","tags":["report"]},{"url":"https://ubuntu.com/security/notices/USN-7879-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7879-2","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7880-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7879-3","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7879-4","tags":["advisory"]},{"url":"https://ubuntu.com/security/notices/USN-7934-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2024-36331","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38335","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38349","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38351","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38437","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38438","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38439","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38440","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38441","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38443","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38444","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38445","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38446","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38448","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38449","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38450","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38451","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38452","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38453","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38454","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38455","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38456","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38457","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38458","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38459","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38460","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38461","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38462","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38463","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38464","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38465","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38466","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38467","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38468","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38469","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38470","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38471","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38472","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38473","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38474","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38475","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38476","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38478","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38480","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38481","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38482","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38483","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38484","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38485","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38487","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38488","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38489","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38490","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38491","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38492","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38493","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38494","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38495","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38496","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38497","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38501","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38503","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38505","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38506","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38507","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38508","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38509","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38510","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38511","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38512","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38513","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38514","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38515","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38516","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38517","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38520","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38521","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38524","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38525","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38526","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38527","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38528","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38529","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38530","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38531","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38532","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38533","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38534","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38535","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38537","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38538","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38539","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38540","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38542","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38543","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38544","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38545","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38546","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38547","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38548","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38549","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38550","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38551","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38552","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38553","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38555","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38556","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38557","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38558","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38559","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38560","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38561","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38562","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38563","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38565","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38566","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38567","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38568","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38569","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38570","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38571","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38572","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38573","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38574","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38576","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38577","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38578","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38579","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38581","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38582","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38583","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38584","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38585","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38586","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38587","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38588","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38589","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38590","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38593","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38595","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38601","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38602","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38604","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38605","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38606","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38608","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38609","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38610","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38612","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38615","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38616","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38619","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38622","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38623","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38624","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38625","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38626","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38628","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38629","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38630","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38631","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38632","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38634","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38635","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38639","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38640","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38642","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38643","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38644","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38645","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38646","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38648","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38649","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38650","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38652","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38653","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38654","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38655","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38659","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38660","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38662","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38663","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38664","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38665","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38666","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38668","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38670","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38671","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38675","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-38678","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39726","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39727","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39730","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39731","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39732","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39734","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39809","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39818","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-40157","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39946","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39964","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-39993","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-40018","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-40300","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2025-39725","title":"mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn't in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u003e trigger BUG_ON due to\n  unmap_poisoned_folio couldn't\n   handle large folio\n\n[tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]","status":"published","published":"2025-09-05T17:27:18.719Z","modified":"2026-05-23T16:00:35.031Z","updated_at":"2026-11-02T14:32:50.176138Z"}],"euvd":[{"id":"EUVD-2025-33997","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn't in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u003e trigger BUG_ON due to\n  unmap_poisoned_folio couldn't\n   handle large folio\n\n[tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]","status":"published","published":"2025-09-05T17:27:18Z","modified":"2026-05-23T16:00:35Z","updated_at":"2026-11-02T18:21:09.1995Z"}],"ghsa":[{"id":"GHSA-qmpx-wcm9-r94f","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned...","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn't in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u003e trigger BUG_ON due to\n  unmap_poisoned_folio couldn't\n   handle large folio\n\n[tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]","status":"published","published":"2025-09-05T18:31:27Z","modified":"2025-11-25T21:33:09Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-476"],"updated_at":"2026-11-02T15:04:57.523321Z"}],"nvd":[{"id":"CVE-2025-39725","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn't in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u003e trigger BUG_ON due to\n  unmap_poisoned_folio couldn't\n   handle large folio\n\n[tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]","status":"published","published":"2025-09-05T18:15:50.32Z","modified":"2026-10-19T21:10:00.16Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"primary"}],"cwes":["CWE-476"],"updated_at":"2026-11-02T14:11:27.73916Z"}],"osv":[{"id":"BELL-CVE-2025-39725","status":"published","published":"2025-09-06T06:02:16.745381Z","modified":"2026-06-25T07:18:29.630054396Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:28:22.246535Z"},{"id":"DEBIAN-CVE-2025-39725","description":"In the Linux kernel, the following vulnerability has been resolved:  mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list  In shrink_folio_list(), the hwpoisoned folio may be large folio, which can't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one() must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then retry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of pvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache.  Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough.  memory_failure() will handle it if the UCE is triggered again.  This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic.  The race is as follows:  cpu0      cpu1  shrink_folio_list memory_failure   TestSetPageHWPoison   unmap_poisoned_folio   --\u003e trigger BUG_ON due to   unmap_poisoned_folio couldn't    handle large folio  [tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]","status":"published","published":"2025-09-05T18:15:50.32Z","modified":"2026-10-23T18:04:12.211271585Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:45:46.626332Z"},{"id":"OESA-2025-2632","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\nSUNRPC: make sure cache entry active before cache_show\n\nThe function `c_show` was called with protection from RCU. This only\nensures that `cp` will not be freed. Therefore, the reference count for\n`cp` can drop to zero, which will trigger a refcount use-after-free\nwarning when `cache_get` is called. To resolve this issue, use\n`cache_get_rcu` to ensure that `cp` remains active.\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 7 PID: 822 at lib/refcount.c:25\nrefcount_warn_saturate+0xb1/0x120\nCPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb1/0x120\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n c_show+0x2fc/0x380 [sunrpc]\n seq_read_iter+0x589/0x770\n seq_read+0x1e5/0x270\n proc_reg_read+0xe1/0x140\n vfs_read+0x125/0x530\n ksys_read+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53174)\n\nIn the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table  0 8192 linear /dev/sdc 0 dmsetup create cdata --table  0 65536 linear /dev/sdc 8192 dmsetup create corig --table  0 524288 linear /dev/sdc $262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table  0 524288 cache /dev/mapper/cmeta  /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192  2\u0026gt;/dev/null | hexdump -e  1/8  %u n  )ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056))  2\u0026gt;/dev/null | hexdump -e  1/8  %u n  )dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table  0 8192 linear /dev/sdc 0 dmsetup create cdata --table  0 65536 linear /dev/sdc 8192 dmsetup create corig --table  0 524288 linear /dev/sdc $262144 dmsetup create cache --table  0 524288 cache /dev/mapper/cmeta  /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the  array_cursor/damaged  test in dm-unit:  dm-unit run /pdata/array_cursor/damaged --kernel-dir \u0026lt;KERNEL_DIR\u0026gt;(CVE-2024-57929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u0026gt; trigger BUG_ON due to\n  unmap_poisoned_folio couldn\u0026apos;t\n   handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rc: fix races with imon_disconnect()\n\nSyzbot reports a KASAN issue as below:\nBUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]\nBUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627\nRead of size 4 at addr ffff8880256fb000 by task syz-executor314/4465\n\nCPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\nprint_address_description mm/kasan/report.c:317 [inline]\nprint_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433\nkasan_report+0xb1/0x1e0 mm/kasan/report.c:495\n__create_pipe include/linux/usb.h:1945 [inline]\nsend_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627\nvfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991\nvfs_write+0x2d7/0xdd0 fs/read_write.c:576\nksys_write+0x127/0x250 fs/read_write.c:631\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe iMON driver improperly releases the usb_device reference in\nimon_disconnect without coordinating with active users of the\ndevice.\n\nSpecifically, the fields usbdev_intf0 and usbdev_intf1 are not\nprotected by the users counter (ictx-\u0026gt;users). During probe,\nimon_init_intf0 or imon_init_intf1 increments the usb_device\nreference count depending on the interface. However, during\ndisconnect, usb_put_dev is called unconditionally, regardless of\nactual usage.\n\nAs a result, if vfd_write or other operations are still in\nprogress after disconnect, this can lead to a use-after-free of\nthe usb_device pointer.\n\nThread 1 vfd_write                      Thread 2 imon_disconnect\n                                        ...\n                                        if\n                                          usb_put_dev(ictx-\u0026gt;usbdev_intf0)\n                                        else\n                                          usb_put_dev(ictx-\u0026gt;usbdev_intf1)\n...\nwhile\n  send_packet\n    if\n      pipe = usb_sndintpipe(\n        ictx-\u0026gt;usbdev_intf0) UAF\n    else\n      pipe = usb_sndctrlpipe(\n        ictx-\u0026gt;usbdev_intf0, 0) UAF\n\nGuard access to usbdev_intf0 and usbdev_intf1 after disconnect by\nchecking ictx-\u0026gt;disconnected in all writer paths. Add early return\nwith -ENODEV in send_packet(), vfd_write(), lcd_write() and\ndisplay_open() if the device is no longer present.\n\nSet and read ictx-\u0026gt;disconnected under ictx-\u0026gt;lock to ensure memory\nsynchronization. Acquire the lock in imon_disconnect() before setting\nthe flag to synchronize with any ongoing operations.\n\nEnsure writers exit early and safely after disconnect before the USB\ncore proceeds with cleanup.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-39993)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call-\u0026gt;perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability exists in the UDF filesystem\u0026apos;s handling of Allocation Extent Descriptors. When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and trigger a KASAN use-after-free read. This vulnerability was found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-40044)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (\u0026gt;= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)","status":"published","published":"2025-11-07T11:09:45Z","modified":"2026-08-18T01:19:18.568110676Z","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:44.957082Z"},{"id":"OESA-2025-2633","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:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst:   Some memory may share the same node as a CPU, and others are provided as  memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a  first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an  index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat:  UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y  index 512 is out of range for type  unsigned long[512]   [...]  Call Trace:   dump_stack   __ubsan_handle_out_of_bounds   load_microcode_amd   request_microcode_amd   reload_store   kernfs_fop_write_iter   vfs_write   ksys_write   do_syscall_64   entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update.  [ bp: Massage commit message, fix typo. ](CVE-2025-21991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: avoid NPD when ASIC does not support DMUB\n\nctx-\u0026gt;dmub_srv will de NULL if the ASIC does not support DMUB, which is\ntested in dm_dmub_sw_init.\n\nHowever, it will be dereferenced in dmub_hw_lock_mgr_cmd if\nshould_use_dmub_lock returns true.\n\nThis has been the case since dmub support has been added for PSR1.\n\nFix this by checking for dmub_srv in should_use_dmub_lock.\n\n[   37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058\n[   37.447808] #PF: supervisor read access in kernel mode\n[   37.452959] #PF: error_code(0x0000) - not-present page\n[   37.458112] PGD 0 P4D 0\n[   37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n[   37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88\n[   37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[   37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0\n[   37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 \u0026lt;48\u0026gt; 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5\n[   37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202\n[   37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358\n[   37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000\n[   37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5\n[   37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000\n[   37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000\n[   37.551725] FS:  0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000\n[   37.559814] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0\n[   37.572697] Call Trace:\n[   37.575152]  \u0026lt;TASK\u0026gt;\n[   37.577258]  ? __die_body+0x66/0xb0\n[   37.580756]  ? page_fault_oops+0x3e7/0x4a0\n[   37.584861]  ? exc_page_fault+0x3e/0xe0\n[   37.588706]  ? exc_page_fault+0x5c/0xe0\n[   37.592550]  ? asm_exc_page_fault+0x22/0x30\n[   37.596742]  ? dmub_hw_lock_mgr_cmd+0x77/0xb0\n[   37.601107]  dcn10_cursor_lock+0x1e1/0x240\n[   37.605211]  program_cursor_attributes+0x81/0x190\n[   37.609923]  commit_planes_for_stream+0x998/0x1ef0\n[   37.614722]  update_planes_and_stream_v2+0x41e/0x5c0\n[   37.619703]  dc_update_planes_and_stream+0x78/0x140\n[   37.624588]  amdgpu_dm_atomic_commit_tail+0x4362/0x49f0\n[   37.629832]  ? srso_return_thunk+0x5/0x5f\n[   37.633847]  ? mark_held_locks+0x6d/0xd0\n[   37.637774]  ? _raw_spin_unlock_irq+0x24/0x50\n[   37.642135]  ? srso_return_thunk+0x5/0x5f\n[   37.646148]  ? lockdep_hardirqs_on+0x95/0x150\n[   37.650510]  ? srso_return_thunk+0x5/0x5f\n[   37.654522]  ? _raw_spin_unlock_irq+0x2f/0x50\n[   37.658883]  ? srso_return_thunk+0x5/0x5f\n[   37.662897]  ? wait_for_common+0x186/0x1c0\n[   37.666998]  ? srso_return_thunk+0x5/0x5f\n[   37.671009]  ? drm_crtc_next_vblank_start+0xc3/0x170\n[   37.675983]  commit_tail+0xf5/0x1c0\n[   37.679478]  drm_atomic_helper_commit+0x2a2/0x2b0\n[   37.684186]  drm_atomic_commit+0xd6/0x100\n[   37.688199]  ? __cfi___drm_printfn_info+0x10/0x10\n[   37.692911]  drm_atomic_helper_update_plane+0xe5/0x130\n[   37.698054]  drm_mode_cursor_common+0x501/0x670\n[   37.702600]  ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[   37.707572]  drm_mode_cursor_ioctl+0x48/0x70\n[   37.711851]  drm_ioctl_kernel+0xf2/0x150\n[   37.715781]  drm_ioctl+0x363/0x590\n[   37.719189]  ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[   37.724165]  amdgpu_drm_ioctl+0x41/0x80\n[   37.728013]  __se_sys_ioctl+0x7f/0xd0\n[   37.731685]  do_syscall_64+0x87/0x100\n[   37.735355]  ? vma_end_read+0x12/0xe0\n[   37.739024]  ? srso_return_thunk+0x5/0x5f\n[   37.743041]  ? find_held_lock+0x47/0xf0\n[   37.746884]  ? vma_end_read+0x12/0xe0\n[   37.750552]  ? srso_return_thunk+0x5/0\n---truncated---(CVE-2025-22093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: Fix unsafe attribute parsing in output_userspace()\n\nThis patch replaces the manual Netlink attribute iteration in\noutput_userspace() with nla_for_each_nested(), which ensures that only\nwell-formed attributes are processed.(CVE-2025-37998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: pcl726: Prevent invalid irq number\n\nThe reproducer passed in an irq number(0x80008000) that was too large,\nwhich triggered the oob.\n\nAdded an interrupt number check to prevent users from passing in an irq\nnumber that was too large.\n\nIf `it-\u0026gt;options[1]` is 31, then `1 \u0026lt;\u0026lt; it-\u0026gt;options[1]` is still invalid\nbecause it shifts a 1-bit into the sign bit (which is UB in C).\nPossible solutions include reducing the upper bound on the\n`it-\u0026gt;options[1]` value to 30 or lower, or using `1U \u0026lt;\u0026lt; it-\u0026gt;options[1]`.\n\nThe old code would just not attempt to request the IRQ if the\n`options[1]` value were invalid.  And it would still configure the\ndevice without interrupts even if the call to `request_irq` returned an\nerror.  So it would be better to combine this test with the test below.(CVE-2025-39685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: pfr_update: Fix the driver update version check\n\nThe security-version-number check should be used rather\nthan the runtime version check for driver updates.\n\nOtherwise, the firmware update would fail when the update binary had\na lower runtime version number than the current one.\n\n[ rjw: Changelog edits ](CVE-2025-39701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u0026gt; trigger BUG_ON due to\n  unmap_poisoned_folio couldn\u0026apos;t\n   handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()\n\nThe function divides number of online CPUs by num_core_siblings, and\nlater checks the divider by zero. This implies a possibility to get\nand divide-by-zero runtime error. Fix it by moving the check prior to\ndivision. This also helps to save one indentation level.(CVE-2025-39742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.(CVE-2025-39782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix lockdep assertion on sync reset unload event\n\nFix lockdep assertion triggered during sync reset unload event. When the\nsync reset flow is initiated using the devlink reload fw_activate\noption, the PF already holds the devlink lock while handling unload\nevent. In this case, delegate sync reset unload event handling back to\nthe devlink callback process to avoid double-locking and resolve the\nlockdep warning.\n\nKernel log:\nWARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40\n[...]\nCall Trace:\n\u0026lt;TASK\u0026gt;\n mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]\n mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]\n process_one_work+0x222/0x640\n worker_thread+0x199/0x350\n kthread+0x10b/0x230\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x8e/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2025-39832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix memory leak in pad_compress_skb\n\nIf alloc_skb() fails in pad_compress_skb(), it returns NULL without\nreleasing the old skb. The caller does:\n\n    skb = pad_compress_skb(ppp, skb);\n    if (!skb)\n        goto drop;\n\ndrop:\n    kfree_skb(skb);\n\nWhen pad_compress_skb() returns NULL, the reference to the old skb is\nlost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.\n\nAlign pad_compress_skb() semantics with realloc(): only free the old\nskb if allocation and compression succeed.  At the call site, use the\nnew_skb variable so the original skb is not lost when pad_compress_skb()\nfails.(CVE-2025-39847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n  CPU1                        CPU2 (close())\n  ----                        ----\n  sock_hold(sk)               sock_hold(sk);\n  lock_sock(sk)   \u0026lt;-- block close()\n  sock_put(sk)\n  bt_accept_unlink(sk)\n    sock_put(sk)  \u0026lt;-- refcnt by bt_accept_enqueue()\n  release_sock(sk)\n                              lock_sock(sk)\n                              sock_put(sk)\n                              bt_accept_unlink(sk)\n                                sock_put(sk)        \u0026lt;-- last refcnt\n                              bt_accept_unlink(sk)  \u0026lt;-- UAF\n\nDepending on the timing, the other thread could show up in the\n\u0026quot;Freed by task\u0026quot; part.\n\nLet\u0026apos;s call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #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\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:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix invalid accesses to ceph_connection_v1_info\n\nThere is a place where generic code in messenger.c is reading and\nanother place where it is writing to con-\u0026gt;v1 union member without\nchecking that the union member is active (i.e. msgr1 is in use).\n\nOn 64-bit systems, con-\u0026gt;v1.auth_retry overlaps with con-\u0026gt;v2.out_iter,\nso such a read is almost guaranteed to return a bogus value instead of\n0 when msgr2 is in use.  This ends up being fairly benign because the\nside effect is just the invalidation of the authorizer and successive\nfetching of new tickets.\n\ncon-\u0026gt;v1.connect_seq overlaps with con-\u0026gt;v2.conn_bufs and the fact that\nit\u0026apos;s being written to can cause more serious consequences, but luckily\nit\u0026apos;s not something that happens often.(CVE-2025-39880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Check encryption key size on incoming connection\n\nThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case:\n  Security Mode 4 Level 4, Responder - Invalid Encryption Key Size\n  - 128 bit\n\nThis tests the security key with size from 1 to 15 bytes while the\nSecurity Mode 4 Level 4 requests 16 bytes key size.\n\nCurrently PTS fails with the following logs:\n- expected:Connection Response:\n    Code: [3 (0x03)] Code\n    Identifier: (lt)WildCard: Exists(gt)\n    Length: [8 (0x0008)]\n    Destination CID: (lt)WildCard: Exists(gt)\n    Source CID: [64 (0x0040)]\n    Result: [3 (0x0003)] Connection refused - Security block\n    Status: (lt)WildCard: Exists(gt),\nbut received:Connection Response:\n    Code: [3 (0x03)] Code\n    Identifier: [1 (0x01)]\n    Length: [8 (0x0008)]\n    Destination CID: [64 (0x0040)]\n    Source CID: [64 (0x0040)]\n    Result: [0 (0x0000)] Connection Successful\n    Status: [0 (0x0000)] No further information available\n\nAnd HCI logs:\n\u0026lt; HCI Command: Read Encrypti.. (0x05|0x0008) plen 2\n        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n\u0026gt; HCI Event: Command Complete (0x0e) plen 7\n      Read Encryption Key Size (0x05|0x0008) ncmd 1\n        Status: Success (0x00)\n        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n        Key size: 7\n\u0026gt; ACL Data RX: Handle 14 flags 0x02 dlen 12\n      L2CAP: Connection Request (0x02) ident 1 len 4\n        PSM: 4097 (0x1001)\n        Source CID: 64\n\u0026lt; ACL Data TX: Handle 14 flags 0x00 dlen 16\n      L2CAP: Connection Response (0x03) ident 1 len 8\n        Destination CID: 64\n        Source CID: 64\n        Result: Connection successful (0x0000)\n        Status: No further information available (0x0000)(CVE-2025-39889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item \u0026apos;delete_task\u0026apos; has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup)              | CPU 1 (delayed work callback)\ncnic_netdev_event()          |\n  cnic_stop_hw()             | cnic_delete_task()\n    cnic_cm_stop_bnx2x_hw()  | ...\n      cancel_delayed_work()  | /* the queue_delayed_work()\n      flush_workqueue()      |    executes after flush_workqueue()*/\n                             | queue_delayed_work()\n  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance\n                             |   dev = cp-\u0026gt;dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays — such as inserting calls to ssleep()\nwithin the cnic_delete_task() function — to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: Don\u0026apos;t collect too many protection override GRC elements\n\nIn the protection override dump path, the firmware can return far too\nmany GRC elements, resulting in attempting to write past the end of the\npreviously-kmalloc\u0026apos;ed dump buffer.\n\nThis will result in a kernel panic with reason:\n\n BUG: unable to handle kernel paging request at ADDRESS\n\nwhere \u0026quot;ADDRESS\u0026quot; is just past the end of the protection override dump\nbuffer. The start address of the buffer is:\n p_hwfn-\u0026gt;cdev-\u0026gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf\nand the size of the buffer is buf_size in the same data structure.\n\nThe panic can be arrived at from either the qede Ethernet driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc02662ed [qed]\n qed_dbg_protection_override_dump at ffffffffc0267792 [qed]\n qed_dbg_feature at ffffffffc026aa8f [qed]\n qed_dbg_all_data at ffffffffc026b211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]\n devlink_health_do_dump at ffffffff82497f61\n devlink_health_report at ffffffff8249cf29\n qed_report_fatal_error at ffffffffc0272baf [qed]\n qede_sp_task at ffffffffc045ed32 [qede]\n process_one_work at ffffffff81d19783\n\nor the qedf storage driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc068b2ed [qed]\n qed_dbg_protection_override_dump at ffffffffc068c792 [qed]\n qed_dbg_feature at ffffffffc068fa8f [qed]\n qed_dbg_all_data at ffffffffc0690211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]\n devlink_health_do_dump at ffffffff8aa95e51\n devlink_health_report at ffffffff8aa9ae19\n qed_report_fatal_error at ffffffffc0697baf [qed]\n qed_hw_err_notify at ffffffffc06d32d7 [qed]\n qed_spq_post at ffffffffc06b1011 [qed]\n qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]\n qedf_cleanup_fcport at ffffffffc05e7597 [qedf]\n qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]\n fc_rport_work at ffffffffc02da715 [libfc]\n process_one_work at ffffffff8a319663\n\nResolve this by clamping the firmware\u0026apos;s return value to the maximum\nnumber of legal elements the firmware should return.(CVE-2025-39949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix validation of VF state in get resources\n\nVF state I40E_VF_STATE_ACTIVE is not the only state in which\nVF is actually active so it should not be used to determine\nif a VF is allowed to obtain resources.\n\nUse I40E_VF_STATE_RESOURCES_LOADED that is set only in\ni40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix input validation logic for action_meta\n\nFix condition to check \u0026apos;greater or equal\u0026apos; to prevent OOB dereference.(CVE-2025-39970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix idx validation in i40e_validate_queue_map\n\nEnsure idx is within range of active/initialized TCs when iterating over\nvf-\u0026gt;ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Prevent use-after-free during requeue-PI\n\nsyzbot managed to trigger the following race:\n\n   T1                               T2\n\n futex_wait_requeue_pi()\n   futex_do_wait()\n     schedule()\n                               futex_requeue()\n                                 futex_proxy_trylock_atomic()\n                                   futex_requeue_pi_prepare()\n                                   requeue_pi_wake_futex()\n                                     futex_requeue_pi_complete()\n                                      /* preempt */\n\n         * timeout/ signal wakes T1 *\n\n   futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED\n   futex_hash_put()\n  // back to userland, on stack futex_q is garbage\n\n                                      /* back */\n                                     wake_up_state(q-\u0026gt;task, TASK_NORMAL);\n\nIn this scenario futex_wait_requeue_pi() is able to leave without using\nfutex_q::lock_ptr for synchronization.\n\nThis can be prevented by reading futex_q::task before updating the\nfutex_q::requeue_state. A reference on the task_struct is not needed\nbecause requeue_pi_wake_futex() is invoked with a spinlock_t held which\nimplies a RCU read section.\n\nEven if T1 terminates immediately after, the task_struct will remain valid\nduring T2\u0026apos;s wake_up_state().  A READ_ONCE on futex_q::task before\nfutex_requeue_pi_complete() is enough because it ensures that the variable\nis read before the state is updated.\n\nRead futex_q::task before updating the requeue state, use it for the\nfollowing wakeup.(CVE-2025-39977)\n\nIn the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call-\u0026gt;perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (\u0026gt;= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)","status":"published","published":"2025-11-07T11:09:45Z","modified":"2026-08-18T01:19:19.886800712Z","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:44.957082Z"},{"id":"OESA-2025-2634","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:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst:   Some memory may share the same node as a CPU, and others are provided as  memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a  first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an  index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat:  UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y  index 512 is out of range for type  unsigned long[512]   [...]  Call Trace:   dump_stack   __ubsan_handle_out_of_bounds   load_microcode_amd   request_microcode_amd   reload_store   kernfs_fop_write_iter   vfs_write   ksys_write   do_syscall_64   entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update.  [ bp: Massage commit message, fix typo. ](CVE-2025-21991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: avoid NPD when ASIC does not support DMUB\n\nctx-\u0026gt;dmub_srv will de NULL if the ASIC does not support DMUB, which is\ntested in dm_dmub_sw_init.\n\nHowever, it will be dereferenced in dmub_hw_lock_mgr_cmd if\nshould_use_dmub_lock returns true.\n\nThis has been the case since dmub support has been added for PSR1.\n\nFix this by checking for dmub_srv in should_use_dmub_lock.\n\n[   37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058\n[   37.447808] #PF: supervisor read access in kernel mode\n[   37.452959] #PF: error_code(0x0000) - not-present page\n[   37.458112] PGD 0 P4D 0\n[   37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n[   37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88\n[   37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[   37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0\n[   37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 \u0026lt;48\u0026gt; 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5\n[   37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202\n[   37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358\n[   37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000\n[   37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5\n[   37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000\n[   37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000\n[   37.551725] FS:  0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000\n[   37.559814] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0\n[   37.572697] Call Trace:\n[   37.575152]  \u0026lt;TASK\u0026gt;\n[   37.577258]  ? __die_body+0x66/0xb0\n[   37.580756]  ? page_fault_oops+0x3e7/0x4a0\n[   37.584861]  ? exc_page_fault+0x3e/0xe0\n[   37.588706]  ? exc_page_fault+0x5c/0xe0\n[   37.592550]  ? asm_exc_page_fault+0x22/0x30\n[   37.596742]  ? dmub_hw_lock_mgr_cmd+0x77/0xb0\n[   37.601107]  dcn10_cursor_lock+0x1e1/0x240\n[   37.605211]  program_cursor_attributes+0x81/0x190\n[   37.609923]  commit_planes_for_stream+0x998/0x1ef0\n[   37.614722]  update_planes_and_stream_v2+0x41e/0x5c0\n[   37.619703]  dc_update_planes_and_stream+0x78/0x140\n[   37.624588]  amdgpu_dm_atomic_commit_tail+0x4362/0x49f0\n[   37.629832]  ? srso_return_thunk+0x5/0x5f\n[   37.633847]  ? mark_held_locks+0x6d/0xd0\n[   37.637774]  ? _raw_spin_unlock_irq+0x24/0x50\n[   37.642135]  ? srso_return_thunk+0x5/0x5f\n[   37.646148]  ? lockdep_hardirqs_on+0x95/0x150\n[   37.650510]  ? srso_return_thunk+0x5/0x5f\n[   37.654522]  ? _raw_spin_unlock_irq+0x2f/0x50\n[   37.658883]  ? srso_return_thunk+0x5/0x5f\n[   37.662897]  ? wait_for_common+0x186/0x1c0\n[   37.666998]  ? srso_return_thunk+0x5/0x5f\n[   37.671009]  ? drm_crtc_next_vblank_start+0xc3/0x170\n[   37.675983]  commit_tail+0xf5/0x1c0\n[   37.679478]  drm_atomic_helper_commit+0x2a2/0x2b0\n[   37.684186]  drm_atomic_commit+0xd6/0x100\n[   37.688199]  ? __cfi___drm_printfn_info+0x10/0x10\n[   37.692911]  drm_atomic_helper_update_plane+0xe5/0x130\n[   37.698054]  drm_mode_cursor_common+0x501/0x670\n[   37.702600]  ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[   37.707572]  drm_mode_cursor_ioctl+0x48/0x70\n[   37.711851]  drm_ioctl_kernel+0xf2/0x150\n[   37.715781]  drm_ioctl+0x363/0x590\n[   37.719189]  ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[   37.724165]  amdgpu_drm_ioctl+0x41/0x80\n[   37.728013]  __se_sys_ioctl+0x7f/0xd0\n[   37.731685]  do_syscall_64+0x87/0x100\n[   37.735355]  ? vma_end_read+0x12/0xe0\n[   37.739024]  ? srso_return_thunk+0x5/0x5f\n[   37.743041]  ? find_held_lock+0x47/0xf0\n[   37.746884]  ? vma_end_read+0x12/0xe0\n[   37.750552]  ? srso_return_thunk+0x5/0\n---truncated---(CVE-2025-22093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: Fix unsafe attribute parsing in output_userspace()\n\nThis patch replaces the manual Netlink attribute iteration in\noutput_userspace() with nla_for_each_nested(), which ensures that only\nwell-formed attributes are processed.(CVE-2025-37998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: pcl726: Prevent invalid irq number\n\nThe reproducer passed in an irq number(0x80008000) that was too large,\nwhich triggered the oob.\n\nAdded an interrupt number check to prevent users from passing in an irq\nnumber that was too large.\n\nIf `it-\u0026gt;options[1]` is 31, then `1 \u0026lt;\u0026lt; it-\u0026gt;options[1]` is still invalid\nbecause it shifts a 1-bit into the sign bit (which is UB in C).\nPossible solutions include reducing the upper bound on the\n`it-\u0026gt;options[1]` value to 30 or lower, or using `1U \u0026lt;\u0026lt; it-\u0026gt;options[1]`.\n\nThe old code would just not attempt to request the IRQ if the\n`options[1]` value were invalid.  And it would still configure the\ndevice without interrupts even if the call to `request_irq` returned an\nerror.  So it would be better to combine this test with the test below.(CVE-2025-39685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: pfr_update: Fix the driver update version check\n\nThe security-version-number check should be used rather\nthan the runtime version check for driver updates.\n\nOtherwise, the firmware update would fail when the update binary had\na lower runtime version number than the current one.\n\n[ rjw: Changelog edits ](CVE-2025-39701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u0026gt; trigger BUG_ON due to\n  unmap_poisoned_folio couldn\u0026apos;t\n   handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()\n\nThe function divides number of online CPUs by num_core_siblings, and\nlater checks the divider by zero. This implies a possibility to get\nand divide-by-zero runtime error. Fix it by moving the check prior to\ndivision. This also helps to save one indentation level.(CVE-2025-39742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.(CVE-2025-39782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix lockdep assertion on sync reset unload event\n\nFix lockdep assertion triggered during sync reset unload event. When the\nsync reset flow is initiated using the devlink reload fw_activate\noption, the PF already holds the devlink lock while handling unload\nevent. In this case, delegate sync reset unload event handling back to\nthe devlink callback process to avoid double-locking and resolve the\nlockdep warning.\n\nKernel log:\nWARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40\n[...]\nCall Trace:\n\u0026lt;TASK\u0026gt;\n mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]\n mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]\n process_one_work+0x222/0x640\n worker_thread+0x199/0x350\n kthread+0x10b/0x230\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x8e/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2025-39832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix memory leak in pad_compress_skb\n\nIf alloc_skb() fails in pad_compress_skb(), it returns NULL without\nreleasing the old skb. The caller does:\n\n    skb = pad_compress_skb(ppp, skb);\n    if (!skb)\n        goto drop;\n\ndrop:\n    kfree_skb(skb);\n\nWhen pad_compress_skb() returns NULL, the reference to the old skb is\nlost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.\n\nAlign pad_compress_skb() semantics with realloc(): only free the old\nskb if allocation and compression succeed.  At the call site, use the\nnew_skb variable so the original skb is not lost when pad_compress_skb()\nfails.(CVE-2025-39847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n  CPU1                        CPU2 (close())\n  ----                        ----\n  sock_hold(sk)               sock_hold(sk);\n  lock_sock(sk)   \u0026lt;-- block close()\n  sock_put(sk)\n  bt_accept_unlink(sk)\n    sock_put(sk)  \u0026lt;-- refcnt by bt_accept_enqueue()\n  release_sock(sk)\n                              lock_sock(sk)\n                              sock_put(sk)\n                              bt_accept_unlink(sk)\n                                sock_put(sk)        \u0026lt;-- last refcnt\n                              bt_accept_unlink(sk)  \u0026lt;-- UAF\n\nDepending on the timing, the other thread could show up in the\n\u0026quot;Freed by task\u0026quot; part.\n\nLet\u0026apos;s call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #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\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:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix invalid accesses to ceph_connection_v1_info\n\nThere is a place where generic code in messenger.c is reading and\nanother place where it is writing to con-\u0026gt;v1 union member without\nchecking that the union member is active (i.e. msgr1 is in use).\n\nOn 64-bit systems, con-\u0026gt;v1.auth_retry overlaps with con-\u0026gt;v2.out_iter,\nso such a read is almost guaranteed to return a bogus value instead of\n0 when msgr2 is in use.  This ends up being fairly benign because the\nside effect is just the invalidation of the authorizer and successive\nfetching of new tickets.\n\ncon-\u0026gt;v1.connect_seq overlaps with con-\u0026gt;v2.conn_bufs and the fact that\nit\u0026apos;s being written to can cause more serious consequences, but luckily\nit\u0026apos;s not something that happens often.(CVE-2025-39880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Check encryption key size on incoming connection\n\nThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case:\n  Security Mode 4 Level 4, Responder - Invalid Encryption Key Size\n  - 128 bit\n\nThis tests the security key with size from 1 to 15 bytes while the\nSecurity Mode 4 Level 4 requests 16 bytes key size.\n\nCurrently PTS fails with the following logs:\n- expected:Connection Response:\n    Code: [3 (0x03)] Code\n    Identifier: (lt)WildCard: Exists(gt)\n    Length: [8 (0x0008)]\n    Destination CID: (lt)WildCard: Exists(gt)\n    Source CID: [64 (0x0040)]\n    Result: [3 (0x0003)] Connection refused - Security block\n    Status: (lt)WildCard: Exists(gt),\nbut received:Connection Response:\n    Code: [3 (0x03)] Code\n    Identifier: [1 (0x01)]\n    Length: [8 (0x0008)]\n    Destination CID: [64 (0x0040)]\n    Source CID: [64 (0x0040)]\n    Result: [0 (0x0000)] Connection Successful\n    Status: [0 (0x0000)] No further information available\n\nAnd HCI logs:\n\u0026lt; HCI Command: Read Encrypti.. (0x05|0x0008) plen 2\n        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n\u0026gt; HCI Event: Command Complete (0x0e) plen 7\n      Read Encryption Key Size (0x05|0x0008) ncmd 1\n        Status: Success (0x00)\n        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n        Key size: 7\n\u0026gt; ACL Data RX: Handle 14 flags 0x02 dlen 12\n      L2CAP: Connection Request (0x02) ident 1 len 4\n        PSM: 4097 (0x1001)\n        Source CID: 64\n\u0026lt; ACL Data TX: Handle 14 flags 0x00 dlen 16\n      L2CAP: Connection Response (0x03) ident 1 len 8\n        Destination CID: 64\n        Source CID: 64\n        Result: Connection successful (0x0000)\n        Status: No further information available (0x0000)(CVE-2025-39889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item \u0026apos;delete_task\u0026apos; has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup)              | CPU 1 (delayed work callback)\ncnic_netdev_event()          |\n  cnic_stop_hw()             | cnic_delete_task()\n    cnic_cm_stop_bnx2x_hw()  | ...\n      cancel_delayed_work()  | /* the queue_delayed_work()\n      flush_workqueue()      |    executes after flush_workqueue()*/\n                             | queue_delayed_work()\n  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance\n                             |   dev = cp-\u0026gt;dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays — such as inserting calls to ssleep()\nwithin the cnic_delete_task() function — to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: Don\u0026apos;t collect too many protection override GRC elements\n\nIn the protection override dump path, the firmware can return far too\nmany GRC elements, resulting in attempting to write past the end of the\npreviously-kmalloc\u0026apos;ed dump buffer.\n\nThis will result in a kernel panic with reason:\n\n BUG: unable to handle kernel paging request at ADDRESS\n\nwhere \u0026quot;ADDRESS\u0026quot; is just past the end of the protection override dump\nbuffer. The start address of the buffer is:\n p_hwfn-\u0026gt;cdev-\u0026gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf\nand the size of the buffer is buf_size in the same data structure.\n\nThe panic can be arrived at from either the qede Ethernet driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc02662ed [qed]\n qed_dbg_protection_override_dump at ffffffffc0267792 [qed]\n qed_dbg_feature at ffffffffc026aa8f [qed]\n qed_dbg_all_data at ffffffffc026b211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]\n devlink_health_do_dump at ffffffff82497f61\n devlink_health_report at ffffffff8249cf29\n qed_report_fatal_error at ffffffffc0272baf [qed]\n qede_sp_task at ffffffffc045ed32 [qede]\n process_one_work at ffffffff81d19783\n\nor the qedf storage driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc068b2ed [qed]\n qed_dbg_protection_override_dump at ffffffffc068c792 [qed]\n qed_dbg_feature at ffffffffc068fa8f [qed]\n qed_dbg_all_data at ffffffffc0690211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]\n devlink_health_do_dump at ffffffff8aa95e51\n devlink_health_report at ffffffff8aa9ae19\n qed_report_fatal_error at ffffffffc0697baf [qed]\n qed_hw_err_notify at ffffffffc06d32d7 [qed]\n qed_spq_post at ffffffffc06b1011 [qed]\n qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]\n qedf_cleanup_fcport at ffffffffc05e7597 [qedf]\n qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]\n fc_rport_work at ffffffffc02da715 [libfc]\n process_one_work at ffffffff8a319663\n\nResolve this by clamping the firmware\u0026apos;s return value to the maximum\nnumber of legal elements the firmware should return.(CVE-2025-39949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix validation of VF state in get resources\n\nVF state I40E_VF_STATE_ACTIVE is not the only state in which\nVF is actually active so it should not be used to determine\nif a VF is allowed to obtain resources.\n\nUse I40E_VF_STATE_RESOURCES_LOADED that is set only in\ni40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix input validation logic for action_meta\n\nFix condition to check \u0026apos;greater or equal\u0026apos; to prevent OOB dereference.(CVE-2025-39970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix idx validation in i40e_validate_queue_map\n\nEnsure idx is within range of active/initialized TCs when iterating over\nvf-\u0026gt;ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Prevent use-after-free during requeue-PI\n\nsyzbot managed to trigger the following race:\n\n   T1                               T2\n\n futex_wait_requeue_pi()\n   futex_do_wait()\n     schedule()\n                               futex_requeue()\n                                 futex_proxy_trylock_atomic()\n                                   futex_requeue_pi_prepare()\n                                   requeue_pi_wake_futex()\n                                     futex_requeue_pi_complete()\n                                      /* preempt */\n\n         * timeout/ signal wakes T1 *\n\n   futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED\n   futex_hash_put()\n  // back to userland, on stack futex_q is garbage\n\n                                      /* back */\n                                     wake_up_state(q-\u0026gt;task, TASK_NORMAL);\n\nIn this scenario futex_wait_requeue_pi() is able to leave without using\nfutex_q::lock_ptr for synchronization.\n\nThis can be prevented by reading futex_q::task before updating the\nfutex_q::requeue_state. A reference on the task_struct is not needed\nbecause requeue_pi_wake_futex() is invoked with a spinlock_t held which\nimplies a RCU read section.\n\nEven if T1 terminates immediately after, the task_struct will remain valid\nduring T2\u0026apos;s wake_up_state().  A READ_ONCE on futex_q::task before\nfutex_requeue_pi_complete() is enough because it ensures that the variable\nis read before the state is updated.\n\nRead futex_q::task before updating the requeue state, use it for the\nfollowing wakeup.(CVE-2025-39977)\n\nIn the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call-\u0026gt;perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (\u0026gt;= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)","status":"published","published":"2025-11-07T11:09:45Z","modified":"2026-08-18T01:19:18.739803611Z","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:44.957082Z"},{"id":"OESA-2025-2635","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:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst:   Some memory may share the same node as a CPU, and others are provided as  memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a  first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an  index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat:  UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y  index 512 is out of range for type  unsigned long[512]   [...]  Call Trace:   dump_stack   __ubsan_handle_out_of_bounds   load_microcode_amd   request_microcode_amd   reload_store   kernfs_fop_write_iter   vfs_write   ksys_write   do_syscall_64   entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update.  [ bp: Massage commit message, fix typo. ](CVE-2025-21991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: Fix unsafe attribute parsing in output_userspace()\n\nThis patch replaces the manual Netlink attribute iteration in\noutput_userspace() with nla_for_each_nested(), which ensures that only\nwell-formed attributes are processed.(CVE-2025-37998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: pcl726: Prevent invalid irq number\n\nThe reproducer passed in an irq number(0x80008000) that was too large,\nwhich triggered the oob.\n\nAdded an interrupt number check to prevent users from passing in an irq\nnumber that was too large.\n\nIf `it-\u0026gt;options[1]` is 31, then `1 \u0026lt;\u0026lt; it-\u0026gt;options[1]` is still invalid\nbecause it shifts a 1-bit into the sign bit (which is UB in C).\nPossible solutions include reducing the upper bound on the\n`it-\u0026gt;options[1]` value to 30 or lower, or using `1U \u0026lt;\u0026lt; it-\u0026gt;options[1]`.\n\nThe old code would just not attempt to request the IRQ if the\n`options[1]` value were invalid.  And it would still configure the\ndevice without interrupts even if the call to `request_irq` returned an\nerror.  So it would be better to combine this test with the test below.(CVE-2025-39685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: pfr_update: Fix the driver update version check\n\nThe security-version-number check should be used rather\nthan the runtime version check for driver updates.\n\nOtherwise, the firmware update would fail when the update binary had\na lower runtime version number than the current one.\n\n[ rjw: Changelog edits ](CVE-2025-39701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u0026gt; trigger BUG_ON due to\n  unmap_poisoned_folio couldn\u0026apos;t\n   handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()\n\nThe function divides number of online CPUs by num_core_siblings, and\nlater checks the divider by zero. This implies a possibility to get\nand divide-by-zero runtime error. Fix it by moving the check prior to\ndivision. This also helps to save one indentation level.(CVE-2025-39742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.(CVE-2025-39782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix lockdep assertion on sync reset unload event\n\nFix lockdep assertion triggered during sync reset unload event. When the\nsync reset flow is initiated using the devlink reload fw_activate\noption, the PF already holds the devlink lock while handling unload\nevent. In this case, delegate sync reset unload event handling back to\nthe devlink callback process to avoid double-locking and resolve the\nlockdep warning.\n\nKernel log:\nWARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40\n[...]\nCall Trace:\n\u0026lt;TASK\u0026gt;\n mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]\n mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]\n process_one_work+0x222/0x640\n worker_thread+0x199/0x350\n kthread+0x10b/0x230\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x8e/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2025-39832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix memory leak in pad_compress_skb\n\nIf alloc_skb() fails in pad_compress_skb(), it returns NULL without\nreleasing the old skb. The caller does:\n\n    skb = pad_compress_skb(ppp, skb);\n    if (!skb)\n        goto drop;\n\ndrop:\n    kfree_skb(skb);\n\nWhen pad_compress_skb() returns NULL, the reference to the old skb is\nlost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.\n\nAlign pad_compress_skb() semantics with realloc(): only free the old\nskb if allocation and compression succeed.  At the call site, use the\nnew_skb variable so the original skb is not lost when pad_compress_skb()\nfails.(CVE-2025-39847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n  CPU1                        CPU2 (close())\n  ----                        ----\n  sock_hold(sk)               sock_hold(sk);\n  lock_sock(sk)   \u0026lt;-- block close()\n  sock_put(sk)\n  bt_accept_unlink(sk)\n    sock_put(sk)  \u0026lt;-- refcnt by bt_accept_enqueue()\n  release_sock(sk)\n                              lock_sock(sk)\n                              sock_put(sk)\n                              bt_accept_unlink(sk)\n                                sock_put(sk)        \u0026lt;-- last refcnt\n                              bt_accept_unlink(sk)  \u0026lt;-- UAF\n\nDepending on the timing, the other thread could show up in the\n\u0026quot;Freed by task\u0026quot; part.\n\nLet\u0026apos;s call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #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\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:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix invalid accesses to ceph_connection_v1_info\n\nThere is a place where generic code in messenger.c is reading and\nanother place where it is writing to con-\u0026gt;v1 union member without\nchecking that the union member is active (i.e. msgr1 is in use).\n\nOn 64-bit systems, con-\u0026gt;v1.auth_retry overlaps with con-\u0026gt;v2.out_iter,\nso such a read is almost guaranteed to return a bogus value instead of\n0 when msgr2 is in use.  This ends up being fairly benign because the\nside effect is just the invalidation of the authorizer and successive\nfetching of new tickets.\n\ncon-\u0026gt;v1.connect_seq overlaps with con-\u0026gt;v2.conn_bufs and the fact that\nit\u0026apos;s being written to can cause more serious consequences, but luckily\nit\u0026apos;s not something that happens often.(CVE-2025-39880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Check encryption key size on incoming connection\n\nThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case:\n  Security Mode 4 Level 4, Responder - Invalid Encryption Key Size\n  - 128 bit\n\nThis tests the security key with size from 1 to 15 bytes while the\nSecurity Mode 4 Level 4 requests 16 bytes key size.\n\nCurrently PTS fails with the following logs:\n- expected:Connection Response:\n    Code: [3 (0x03)] Code\n    Identifier: (lt)WildCard: Exists(gt)\n    Length: [8 (0x0008)]\n    Destination CID: (lt)WildCard: Exists(gt)\n    Source CID: [64 (0x0040)]\n    Result: [3 (0x0003)] Connection refused - Security block\n    Status: (lt)WildCard: Exists(gt),\nbut received:Connection Response:\n    Code: [3 (0x03)] Code\n    Identifier: [1 (0x01)]\n    Length: [8 (0x0008)]\n    Destination CID: [64 (0x0040)]\n    Source CID: [64 (0x0040)]\n    Result: [0 (0x0000)] Connection Successful\n    Status: [0 (0x0000)] No further information available\n\nAnd HCI logs:\n\u0026lt; HCI Command: Read Encrypti.. (0x05|0x0008) plen 2\n        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n\u0026gt; HCI Event: Command Complete (0x0e) plen 7\n      Read Encryption Key Size (0x05|0x0008) ncmd 1\n        Status: Success (0x00)\n        Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)\n        Key size: 7\n\u0026gt; ACL Data RX: Handle 14 flags 0x02 dlen 12\n      L2CAP: Connection Request (0x02) ident 1 len 4\n        PSM: 4097 (0x1001)\n        Source CID: 64\n\u0026lt; ACL Data TX: Handle 14 flags 0x00 dlen 16\n      L2CAP: Connection Response (0x03) ident 1 len 8\n        Destination CID: 64\n        Source CID: 64\n        Result: Connection successful (0x0000)\n        Status: No further information available (0x0000)(CVE-2025-39889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item \u0026apos;delete_task\u0026apos; has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup)              | CPU 1 (delayed work callback)\ncnic_netdev_event()          |\n  cnic_stop_hw()             | cnic_delete_task()\n    cnic_cm_stop_bnx2x_hw()  | ...\n      cancel_delayed_work()  | /* the queue_delayed_work()\n      flush_workqueue()      |    executes after flush_workqueue()*/\n                             | queue_delayed_work()\n  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance\n                             |   dev = cp-\u0026gt;dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays — such as inserting calls to ssleep()\nwithin the cnic_delete_task() function — to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: Don\u0026apos;t collect too many protection override GRC elements\n\nIn the protection override dump path, the firmware can return far too\nmany GRC elements, resulting in attempting to write past the end of the\npreviously-kmalloc\u0026apos;ed dump buffer.\n\nThis will result in a kernel panic with reason:\n\n BUG: unable to handle kernel paging request at ADDRESS\n\nwhere \u0026quot;ADDRESS\u0026quot; is just past the end of the protection override dump\nbuffer. The start address of the buffer is:\n p_hwfn-\u0026gt;cdev-\u0026gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf\nand the size of the buffer is buf_size in the same data structure.\n\nThe panic can be arrived at from either the qede Ethernet driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc02662ed [qed]\n qed_dbg_protection_override_dump at ffffffffc0267792 [qed]\n qed_dbg_feature at ffffffffc026aa8f [qed]\n qed_dbg_all_data at ffffffffc026b211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]\n devlink_health_do_dump at ffffffff82497f61\n devlink_health_report at ffffffff8249cf29\n qed_report_fatal_error at ffffffffc0272baf [qed]\n qede_sp_task at ffffffffc045ed32 [qede]\n process_one_work at ffffffff81d19783\n\nor the qedf storage driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc068b2ed [qed]\n qed_dbg_protection_override_dump at ffffffffc068c792 [qed]\n qed_dbg_feature at ffffffffc068fa8f [qed]\n qed_dbg_all_data at ffffffffc0690211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]\n devlink_health_do_dump at ffffffff8aa95e51\n devlink_health_report at ffffffff8aa9ae19\n qed_report_fatal_error at ffffffffc0697baf [qed]\n qed_hw_err_notify at ffffffffc06d32d7 [qed]\n qed_spq_post at ffffffffc06b1011 [qed]\n qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]\n qedf_cleanup_fcport at ffffffffc05e7597 [qedf]\n qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]\n fc_rport_work at ffffffffc02da715 [libfc]\n process_one_work at ffffffff8a319663\n\nResolve this by clamping the firmware\u0026apos;s return value to the maximum\nnumber of legal elements the firmware should return.(CVE-2025-39949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix validation of VF state in get resources\n\nVF state I40E_VF_STATE_ACTIVE is not the only state in which\nVF is actually active so it should not be used to determine\nif a VF is allowed to obtain resources.\n\nUse I40E_VF_STATE_RESOURCES_LOADED that is set only in\ni40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix input validation logic for action_meta\n\nFix condition to check \u0026apos;greater or equal\u0026apos; to prevent OOB dereference.(CVE-2025-39970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix idx validation in i40e_validate_queue_map\n\nEnsure idx is within range of active/initialized TCs when iterating over\nvf-\u0026gt;ch[idx] in i40e_validate_queue_map().(CVE-2025-39972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Prevent use-after-free during requeue-PI\n\nsyzbot managed to trigger the following race:\n\n   T1                               T2\n\n futex_wait_requeue_pi()\n   futex_do_wait()\n     schedule()\n                               futex_requeue()\n                                 futex_proxy_trylock_atomic()\n                                   futex_requeue_pi_prepare()\n                                   requeue_pi_wake_futex()\n                                     futex_requeue_pi_complete()\n                                      /* preempt */\n\n         * timeout/ signal wakes T1 *\n\n   futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED\n   futex_hash_put()\n  // back to userland, on stack futex_q is garbage\n\n                                      /* back */\n                                     wake_up_state(q-\u0026gt;task, TASK_NORMAL);\n\nIn this scenario futex_wait_requeue_pi() is able to leave without using\nfutex_q::lock_ptr for synchronization.\n\nThis can be prevented by reading futex_q::task before updating the\nfutex_q::requeue_state. A reference on the task_struct is not needed\nbecause requeue_pi_wake_futex() is invoked with a spinlock_t held which\nimplies a RCU read section.\n\nEven if T1 terminates immediately after, the task_struct will remain valid\nduring T2\u0026apos;s wake_up_state().  A READ_ONCE on futex_q::task before\nfutex_requeue_pi_complete() is enough because it ensures that the variable\nis read before the state is updated.\n\nRead futex_q::task before updating the requeue state, use it for the\nfollowing wakeup.(CVE-2025-39977)\n\nIn the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The remove_inode_single_folio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, folio_mapped() returns false and fails to unmap it. Due to the extra refcount held by remove_inode_single_folio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemap_unaccount_folio.(CVE-2025-40006)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call-\u0026gt;perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in max_vclocks_store function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don t block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (\u0026gt;= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway.(CVE-2025-40102)","status":"published","published":"2025-11-07T11:09:45Z","modified":"2026-08-18T01:19:18.977668152Z","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:44.957082Z"},{"id":"OESA-2025-2636","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\ngfs2: Fix possible data races in gfs2_show_options()\n\nSome fields such as gt_logd_secs of the struct gfs2_tune are accessed\nwithout holding the lock gt_spin in gfs2_show_options():\n\n  val = sdp-\u0026gt;sd_tune.gt_logd_secs;\n  if (val != 30)\n    seq_printf(s, \u0026quot;,commit=%d\u0026quot;, val);\n\nAnd thus can cause data races when gfs2_show_options() and other functions\nsuch as gfs2_reconfigure() are concurrently executed:\n\n  spin_lock(\u0026amp;gt-\u0026gt;gt_spin);\n  gt-\u0026gt;gt_logd_secs = newargs-\u0026gt;ar_commit;\n\nTo fix these possible data races, the lock sdp-\u0026gt;sd_tune.gt_spin is\nacquired before accessing the fields of gfs2_tune and released after these\naccesses.\n\nFurther changes by Andreas:\n\n- Don\u0026apos;t hold the spin lock over the seq_printf operations.(CVE-2023-53622)\n\nIn the Linux kernel, a vulnerability exists in the IP checksum code for arm64 architecture. Although commit c2c24edb1d9c (\u0026quot;arm64: csum: Fix pathological zero-length calls\u0026quot;) added an early return for zero-length input, syzkaller has discovered an example of a negative length that causes an undefined shift and an out-of-bounds read. An attacker can exploit this vulnerability to read data beyond the buffer boundary, affecting system confidentiality.(CVE-2023-53726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: make sure cache entry active before cache_show\n\nThe function `c_show` was called with protection from RCU. This only\nensures that `cp` will not be freed. Therefore, the reference count for\n`cp` can drop to zero, which will trigger a refcount use-after-free\nwarning when `cache_get` is called. To resolve this issue, use\n`cache_get_rcu` to ensure that `cp` remains active.\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 7 PID: 822 at lib/refcount.c:25\nrefcount_warn_saturate+0xb1/0x120\nCPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb1/0x120\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n c_show+0x2fc/0x380 [sunrpc]\n seq_read_iter+0x589/0x770\n seq_read+0x1e5/0x270\n proc_reg_read+0xe1/0x140\n vfs_read+0x125/0x530\n ksys_read+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53174)\n\nIn the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table  0 8192 linear /dev/sdc 0 dmsetup create cdata --table  0 65536 linear /dev/sdc 8192 dmsetup create corig --table  0 524288 linear /dev/sdc $262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table  0 524288 cache /dev/mapper/cmeta  /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192  2\u0026gt;/dev/null | hexdump -e  1/8  %u n  )ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056))  2\u0026gt;/dev/null | hexdump -e  1/8  %u n  )dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table  0 8192 linear /dev/sdc 0 dmsetup create cdata --table  0 65536 linear /dev/sdc 8192 dmsetup create corig --table  0 524288 linear /dev/sdc $262144 dmsetup create cache --table  0 524288 cache /dev/mapper/cmeta  /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the  array_cursor/damaged  test in dm-unit:  dm-unit run /pdata/array_cursor/damaged --kernel-dir \u0026lt;KERNEL_DIR\u0026gt;(CVE-2024-57929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u0026gt; trigger BUG_ON due to\n  unmap_poisoned_folio couldn\u0026apos;t\n   handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rc: fix races with imon_disconnect()\n\nSyzbot reports a KASAN issue as below:\nBUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]\nBUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627\nRead of size 4 at addr ffff8880256fb000 by task syz-executor314/4465\n\nCPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\nprint_address_description mm/kasan/report.c:317 [inline]\nprint_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433\nkasan_report+0xb1/0x1e0 mm/kasan/report.c:495\n__create_pipe include/linux/usb.h:1945 [inline]\nsend_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627\nvfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991\nvfs_write+0x2d7/0xdd0 fs/read_write.c:576\nksys_write+0x127/0x250 fs/read_write.c:631\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe iMON driver improperly releases the usb_device reference in\nimon_disconnect without coordinating with active users of the\ndevice.\n\nSpecifically, the fields usbdev_intf0 and usbdev_intf1 are not\nprotected by the users counter (ictx-\u0026gt;users). During probe,\nimon_init_intf0 or imon_init_intf1 increments the usb_device\nreference count depending on the interface. However, during\ndisconnect, usb_put_dev is called unconditionally, regardless of\nactual usage.\n\nAs a result, if vfd_write or other operations are still in\nprogress after disconnect, this can lead to a use-after-free of\nthe usb_device pointer.\n\nThread 1 vfd_write                      Thread 2 imon_disconnect\n                                        ...\n                                        if\n                                          usb_put_dev(ictx-\u0026gt;usbdev_intf0)\n                                        else\n                                          usb_put_dev(ictx-\u0026gt;usbdev_intf1)\n...\nwhile\n  send_packet\n    if\n      pipe = usb_sndintpipe(\n        ictx-\u0026gt;usbdev_intf0) UAF\n    else\n      pipe = usb_sndctrlpipe(\n        ictx-\u0026gt;usbdev_intf0, 0) UAF\n\nGuard access to usbdev_intf0 and usbdev_intf1 after disconnect by\nchecking ictx-\u0026gt;disconnected in all writer paths. Add early return\nwith -ENODEV in send_packet(), vfd_write(), lcd_write() and\ndisplay_open() if the device is no longer present.\n\nSet and read ictx-\u0026gt;disconnected under ictx-\u0026gt;lock to ensure memory\nsynchronization. Acquire the lock in imon_disconnect() before setting\nthe flag to synchronize with any ongoing operations.\n\nEnsure writers exit early and safely after disconnect before the USB\ncore proceeds with cleanup.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-39993)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call-\u0026gt;perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability exists in the UDF filesystem\u0026apos;s handling of Allocation Extent Descriptors. When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and trigger a KASAN use-after-free read. This vulnerability was found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-40044)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (\u0026gt;= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)","status":"published","published":"2025-11-07T11:09:45Z","modified":"2026-08-18T01:19:19.407941187Z","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:44.957082Z"},{"id":"OESA-2025-2659","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\nmisc: tifm: fix possible memory leak in tifm_7xx1_switch_media()\n\nIf device_register() returns error in tifm_7xx1_switch_media(),\nname of kobject which is allocated in dev_set_name() called in device_add()\nis leaked.\n\nNever directly free @dev after calling device_register(), even\nif it returned an error! Always use put_device() to give up the\nreference initialized.(CVE-2022-50349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns: fix possible memory leak in hnae_ae_register()\n\nInject fault while probing module, if device_register() fails,\nbut the refcount of kobject is not decreased to 0, the name\nallocated in dev_set_name() is leaked. Fix this by calling\nput_device(), so that name can be freed in callback function\nkobject_cleanup().\n\nunreferenced object 0xffff00c01aba2100 (size 128):\n  comm \u0026quot;systemd-udevd\u0026quot;, pid 1259, jiffies 4294903284 (age 294.152s)\n  hex dump (first 32 bytes):\n    68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff  hnae0....!......\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;0000000034783f26\u0026gt;] slab_post_alloc_hook+0xa0/0x3e0\n    [\u0026lt;00000000748188f2\u0026gt;] __kmem_cache_alloc_node+0x164/0x2b0\n    [\u0026lt;00000000ab0743e8\u0026gt;] __kmalloc_node_track_caller+0x6c/0x390\n    [\u0026lt;000000006c0ffb13\u0026gt;] kvasprintf+0x8c/0x118\n    [\u0026lt;00000000fa27bfe1\u0026gt;] kvasprintf_const+0x60/0xc8\n    [\u0026lt;0000000083e10ed7\u0026gt;] kobject_set_name_vargs+0x3c/0xc0\n    [\u0026lt;000000000b87affc\u0026gt;] dev_set_name+0x7c/0xa0\n    [\u0026lt;000000003fd8fe26\u0026gt;] hnae_ae_register+0xcc/0x190 [hnae]\n    [\u0026lt;00000000fe97edc9\u0026gt;] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf]\n    [\u0026lt;00000000c36ff1eb\u0026gt;] hns_dsaf_probe+0x548/0x748 [hns_dsaf](CVE-2022-50352)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid crash when inline data creation follows DIO write\n\nWhen inode is created and written to using direct IO, there is nothing\nto clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets\ntruncated later to say 1 byte and written using normal write, we will\ntry to store the data as inline data. This confuses the code later\nbecause the inode now has both normal block and inline data allocated\nand the confusion manifests for example as:\n\nkernel BUG at fs/ext4/inode.c:2721!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN\nCPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014\nRIP: 0010:ext4_writepages+0x363d/0x3660\nRSP: 0018:ffffc90000ccf260 EFLAGS: 00010293\nRAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180\nRDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000\nRBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b\nR10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128\nR13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001\nFS:  00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n do_writepages+0x397/0x640\n filemap_fdatawrite_wbc+0x151/0x1b0\n file_write_and_wait_range+0x1c9/0x2b0\n ext4_sync_file+0x19e/0xa00\n vfs_fsync_range+0x17b/0x190\n ext4_buffered_write_iter+0x488/0x530\n ext4_file_write_iter+0x449/0x1b90\n vfs_write+0xbcd/0xf40\n ksys_write+0x198/0x2c0\n __x64_sys_write+0x7b/0x90\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n \u0026lt;/TASK\u0026gt;\n\nFix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing\ndirect IO write to a file.(CVE-2022-50435)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clean up si_domain in the init_dmars() error path\n\nA splat from kmem_cache_destroy() was seen with a kernel prior to\ncommit ee2653bbe89d (\u0026quot;iommu/vt-d: Remove domain and devinfo mempool\u0026quot;)\nwhen there was a failure in init_dmars(), because the iommu_domain\ncache still had objects. While the mempool code is now gone, there\nstill is a leak of the si_domain memory if init_dmars() fails. So\nclean up si_domain in the init_dmars() error path.(CVE-2022-50482)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Fix potential memory leaks\n\nWhen the driver hits -ENOMEM at allocating a URB or a buffer, it\naborts and goes to the error path that releases the all previously\nallocated resources.  However, when -ENOMEM hits at the middle of the\nsync EP URB allocation loop, the partially allocated URBs might be\nleft without released, because ep-\u0026gt;nurbs is still zero at that point.\n\nFix it by setting ep-\u0026gt;nurbs at first, so that the error handler loops\nover the full URB list.(CVE-2022-50484)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mipi-dsi: Detach devices when removing the host\n\nWhenever the MIPI-DSI host is unregistered, the code of\nmipi_dsi_host_unregister() loops over every device currently found on that\nbus and will unregister it.\n\nHowever, it doesn\u0026apos;t detach it from the bus first, which leads to all kind\nof resource leaks if the host wants to perform some clean up whenever a\ndevice is detached.(CVE-2022-50489)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios()\n\nAs comment of pci_get_class() says, it returns a pci_device with its\nrefcount increased and decreased the refcount for the input parameter\n@from if it is not NULL.\n\nIf we break the loop in radeon_atrm_get_bios() with \u0026apos;pdev\u0026apos; not NULL, we\nneed to call pci_dev_put() to decrease the refcount. Add the missing\npci_dev_put() to avoid refcount leak.(CVE-2022-50520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix an information leak in tipc_topsrv_kern_subscr\n\nUse a 8-byte write to initialize sub.usr_handle in\ntipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized\nwhen issuing setsockopt(..., SOL_TIPC, ...).\nThis resulted in an infoleak reported by KMSAN when the packet was\nreceived:\n\n  =====================================================\n  BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169\n   instrument_copy_to_user ./include/linux/instrumented.h:121\n   copyout+0xbc/0x100 lib/iov_iter.c:169\n   _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527\n   copy_to_iter ./include/linux/uio.h:176\n   simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513\n   __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419\n   skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527\n   skb_copy_datagram_msg ./include/linux/skbuff.h:3903\n   packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469\n   ____sys_recvmsg+0x2c4/0x810 net/socket.c:?\n   ___sys_recvmsg+0x217/0x840 net/socket.c:2743\n   __sys_recvmsg net/socket.c:2773\n   __do_sys_recvmsg net/socket.c:2783\n   __se_sys_recvmsg net/socket.c:2780\n   __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780\n   do_syscall_x64 arch/x86/entry/common.c:50\n   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120\n\n  ...\n\n  Uninit was stored to memory at:\n   tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156\n   tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375\n   tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579\n   tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190\n   tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084\n   tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201\n   __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252\n   __do_sys_setsockopt net/socket.c:2263\n   __se_sys_setsockopt net/socket.c:2260\n   __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260\n   do_syscall_x64 arch/x86/entry/common.c:50\n   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120\n\n  Local variable sub created at:\n   tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562\n   tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190\n\n  Bytes 84-87 of 88 are uninitialized\n  Memory access of size 88 starts at ffff88801ed57cd0\n  Data copied to user address 0000000020000400\n  ...\n  =====================================================(CVE-2022-50531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()\n\nThis patch fixes a shift-out-of-bounds in brcmfmac that occurs in\nBIT(chiprev) when a \u0026apos;chiprev\u0026apos; provided by the device is too large.\nIt should also not be equal to or greater than BITS_PER_TYPE(u32)\nas we do bitwise AND with a u32 variable and BIT(chiprev). The patch\nadds a check that makes the function return NULL if that is the case.\nNote that the NULL case is later handled by the bus-specific caller,\nbrcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.\n\nFound by a modified version of syzkaller.\n\nUBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c\nshift exponent 151055786 is too large for 64-bit type \u0026apos;long unsigned int\u0026apos;\nCPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n dump_stack_lvl+0x57/0x7d\n ubsan_epilogue+0x5/0x40\n __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb\n ? lock_chain_count+0x20/0x20\n brcmf_fw_alloc_request.cold+0x19/0x3ea\n ? brcmf_fw_get_firmwares+0x250/0x250\n ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0\n brcmf_usb_get_fwname+0x114/0x1a0\n ? brcmf_usb_reset_resume+0x120/0x120\n ? number+0x6c4/0x9a0\n brcmf_c_process_clm_blob+0x168/0x590\n ? put_dec+0x90/0x90\n ? enable_ptr_key_workfn+0x20/0x20\n ? brcmf_common_pd_remove+0x50/0x50\n ? rcu_read_lock_sched_held+0xa1/0xd0\n brcmf_c_preinit_dcmds+0x673/0xc40\n ? brcmf_c_set_joinpref_default+0x100/0x100\n ? rcu_read_lock_sched_held+0xa1/0xd0\n ? rcu_read_lock_bh_held+0xb0/0xb0\n ? lock_acquire+0x19d/0x4e0\n ? find_held_lock+0x2d/0x110\n ? brcmf_usb_deq+0x1cc/0x260\n ? mark_held_locks+0x9f/0xe0\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n ? _raw_spin_unlock_irqrestore+0x47/0x50\n ? trace_hardirqs_on+0x1c/0x120\n ? brcmf_usb_deq+0x1a7/0x260\n ? brcmf_usb_rx_fill_all+0x5a/0xf0\n brcmf_attach+0x246/0xd40\n ? wiphy_new_nm+0x1476/0x1d50\n ? kmemdup+0x30/0x40\n brcmf_usb_probe+0x12de/0x1690\n ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n usb_probe_interface+0x25f/0x710\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n ? usb_match_id.part.0+0x88/0xc0\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n ? driver_allows_async_probing+0x120/0x120\n bus_for_each_drv+0x123/0x1a0\n ? bus_rescan_devices+0x20/0x20\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n ? trace_hardirqs_on+0x1c/0x120\n __device_attach+0x207/0x330\n ? device_bind_driver+0xb0/0xb0\n ? kobject_uevent_env+0x230/0x12c0\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n ? __mutex_unlock_slowpath+0xe7/0x660\n ? __fw_devlink_link_to_suppliers+0x550/0x550\n usb_set_configuration+0x984/0x1770\n ? kernfs_create_link+0x175/0x230\n usb_generic_driver_probe+0x69/0x90\n usb_probe_device+0x9c/0x220\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n ? driver_allows_async_probing+0x120/0x120\n bus_for_each_drv+0x123/0x1a0\n ? bus_rescan_devices+0x20/0x20\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n ? trace_hardirqs_on+0x1c/0x120\n __device_attach+0x207/0x330\n ? device_bind_driver+0xb0/0xb0\n ? kobject_uevent_env+0x230/0x12c0\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n ? __fw_devlink_link_to_suppliers+0x550/0x550\n usb_new_device.cold+0x463/0xf66\n ? hub_disconnect+0x400/0x400\n ? _raw_spin_unlock_irq+0x24/0x30\n hub_event+0x10d5/0x3330\n ? hub_port_debounce+0x280/0x280\n ? __lock_acquire+0x1671/0x5790\n ? wq_calc_node_cpumask+0x170/0x2a0\n ? lock_release+0x640/0x640\n ? rcu_read_lock_sched_held+0xa1/0xd0\n ? rcu_read_lock_bh_held+0xb0/0xb0\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n process_one_work+0x873/0x13e0\n ? lock_release+0x640/0x640\n ? pwq_dec_nr_in_flight+0x320/0x320\n ? rwlock_bug.part.0+0x90/0x90\n worker_thread+0x8b/0xd10\n ? __kthread_parkme+0xd9/0x1d0\n ? pr\n---truncated---(CVE-2022-50551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: use quiesced elevator switch when reinitializing queues\n\nThe hctx\u0026apos;s run_work may be racing with the elevator switch when\nreinitializing hardware queues. The queue is merely frozen in this\ncontext, but that only prevents requests from allocating and doesn\u0026apos;t\nstop the hctx work from running. The work may get an elevator pointer\nthat\u0026apos;s being torn down, and can result in use-after-free errors and\nkernel panics (example below). Use the quiesced elevator switch instead,\nand make the previous one static since it is now only used locally.\n\n  nvme nvme0: resetting controller\n  nvme nvme0: 32/0/0 default/read/poll queues\n  BUG: kernel NULL pointer dereference, address: 0000000000000008\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0\n  Oops: 0000 [#1] SMP PTI\n  Workqueue: kblockd blk_mq_run_work_fn\n  RIP: 0010:kyber_has_work+0x29/0x70\n\n...\n\n  Call Trace:\n   __blk_mq_do_dispatch_sched+0x83/0x2b0\n   __blk_mq_sched_dispatch_requests+0x12e/0x170\n   blk_mq_sched_dispatch_requests+0x30/0x60\n   __blk_mq_run_hw_queue+0x2b/0x50\n   process_one_work+0x1ef/0x380\n   worker_thread+0x2d/0x3e0(CVE-2022-50552)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: don\u0026apos;t allow to overwrite ENDPOINT0 attributes\n\nA bad USB device is able to construct a service connection response\nmessage with target endpoint being ENDPOINT0 which is reserved for\nHTC_CTRL_RSVD_SVC and should not be modified to be used for any other\nservices.\n\nReject such service connection responses.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2023-53185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails\n\nSyzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream().\nWhile processing skbs in ath9k_hif_usb_rx_stream(), the already allocated\nskbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If we\nhave an incorrect pkt_len or pkt_tag, the input skb is considered invalid\nand dropped. All the associated packets already in skb_pool should be\ndropped and freed. Added a comment describing this issue.\n\nThe patch also makes remain_skb NULL after being processed so that it\ncannot be referenced after potential free. The initialization of hif_dev\nfields which are associated with remain_skb (rx_remain_len,\nrx_transfer_len and rx_pad_len) is moved after a new remain_skb is\nallocated.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2023-53199)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write\n\nSyzkaller reported the following issue:\n\n=====================================================\nBUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline]\nBUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600\n aio_rw_done fs/aio.c:1520 [inline]\n aio_write+0x899/0x950 fs/aio.c:1600\n io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019\n __do_sys_io_submit fs/aio.c:2078 [inline]\n __se_sys_io_submit+0x293/0x770 fs/aio.c:2048\n __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:766 [inline]\n slab_alloc_node mm/slub.c:3452 [inline]\n __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491\n __do_kmalloc_node mm/slab_common.c:967 [inline]\n __kmalloc+0x11d/0x3b0 mm/slab_common.c:981\n kmalloc_array include/linux/slab.h:636 [inline]\n bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930\n bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg net/socket.c:734 [inline]\n sock_write_iter+0x495/0x5e0 net/socket.c:1108\n call_write_iter include/linux/fs.h:2189 [inline]\n aio_write+0x63a/0x950 fs/aio.c:1600\n io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019\n __do_sys_io_submit fs/aio.c:2078 [inline]\n __se_sys_io_submit+0x293/0x770 fs/aio.c:2048\n __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nCPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023\n=====================================================\n\nWe can follow the call chain and find that \u0026apos;bcm_tx_setup\u0026apos; function\ncalls \u0026apos;memcpy_from_msg\u0026apos; to copy some content to the newly allocated\nframe of \u0026apos;op-\u0026gt;frames\u0026apos;. After that the \u0026apos;len\u0026apos; field of copied structure\nbeing compared with some constant value (64 or 8). However, if\n\u0026apos;memcpy_from_msg\u0026apos; returns an error, we will compare some uninitialized\nmemory. This triggers \u0026apos;uninit-value\u0026apos; issue.\n\nThis patch will add \u0026apos;memcpy_from_msg\u0026apos; possible errors processing to\navoid uninit-value issue.\n\nTested via syzkaller(CVE-2023-53344)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix warning and UAF when destroy the MR list\n\nIf the MR allocate failed, the MR recovery work not initialized\nand list not cleared. Then will be warning and UAF when release\nthe MR:\n\n  WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110\n  CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82\n  RIP: 0010:__flush_work.isra.0+0xf7/0x110\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   __cancel_work_timer+0x2ba/0x2e0\n   smbd_destroy+0x4e1/0x990\n   _smbd_get_connection+0x1cbd/0x2110\n   smbd_get_connection+0x21/0x40\n   cifs_get_tcp_session+0x8ef/0xda0\n   mount_get_conns+0x60/0x750\n   cifs_mount+0x103/0xd00\n   cifs_smb3_do_mount+0x1dd/0xcb0\n   smb3_get_tree+0x1d5/0x300\n   vfs_get_tree+0x41/0xf0\n   path_mount+0x9b3/0xdd0\n   __x64_sys_mount+0x190/0x1d0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n  BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990\n  Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824\n  CPU: 4 PID: 824 Comm: mount.cifs Tainted: G        W          6.1.0-rc5+ #82\n  Call Trace:\n   dump_stack_lvl+0x34/0x44\n   print_report+0x171/0x472\n   kasan_report+0xad/0x130\n   smbd_destroy+0x4fc/0x990\n   _smbd_get_connection+0x1cbd/0x2110\n   smbd_get_connection+0x21/0x40\n   cifs_get_tcp_session+0x8ef/0xda0\n   mount_get_conns+0x60/0x750\n   cifs_mount+0x103/0xd00\n   cifs_smb3_do_mount+0x1dd/0xcb0\n   smb3_get_tree+0x1d5/0x300\n   vfs_get_tree+0x41/0xf0\n   path_mount+0x9b3/0xdd0\n   __x64_sys_mount+0x190/0x1d0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n  Allocated by task 824:\n   kasan_save_stack+0x1e/0x40\n   kasan_set_track+0x21/0x30\n   __kasan_kmalloc+0x7a/0x90\n   _smbd_get_connection+0x1b6f/0x2110\n   smbd_get_connection+0x21/0x40\n   cifs_get_tcp_session+0x8ef/0xda0\n   mount_get_conns+0x60/0x750\n   cifs_mount+0x103/0xd00\n   cifs_smb3_do_mount+0x1dd/0xcb0\n   smb3_get_tree+0x1d5/0x300\n   vfs_get_tree+0x41/0xf0\n   path_mount+0x9b3/0xdd0\n   __x64_sys_mount+0x190/0x1d0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n  Freed by task 824:\n   kasan_save_stack+0x1e/0x40\n   kasan_set_track+0x21/0x30\n   kasan_save_free_info+0x2a/0x40\n   ____kasan_slab_free+0x143/0x1b0\n   __kmem_cache_free+0xc8/0x330\n   _smbd_get_connection+0x1c6a/0x2110\n   smbd_get_connection+0x21/0x40\n   cifs_get_tcp_session+0x8ef/0xda0\n   mount_get_conns+0x60/0x750\n   cifs_mount+0x103/0xd00\n   cifs_smb3_do_mount+0x1dd/0xcb0\n   smb3_get_tree+0x1d5/0x300\n   vfs_get_tree+0x41/0xf0\n   path_mount+0x9b3/0xdd0\n   __x64_sys_mount+0x190/0x1d0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nLet\u0026apos;s initialize the MR recovery work before MR allocate to prevent\nthe warning, remove the MRs from the list to prevent the UAF.(CVE-2023-53427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free\n\nStruct pcie_link_state-\u0026gt;downstream is a pointer to the pci_dev of function\n0.  Previously we retained that pointer when removing function 0, and\nsubsequent ASPM policy changes dereferenced it, resulting in a\nuse-after-free warning from KASAN, e.g.:\n\n  # echo 1 \u0026gt; /sys/bus/pci/devices/0000:03:00.0/remove\n  # echo powersave \u0026gt; /sys/module/pcie_aspm/parameters/policy\n\n  BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500\n  Call Trace:\n   kasan_report+0xae/0xe0\n   pcie_config_aspm_link+0x42d/0x500\n   pcie_aspm_set_policy+0x8e/0x1a0\n   param_attr_store+0x162/0x2c0\n   module_attr_store+0x3e/0x80\n\nPCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM\nControl value in all functions of multi-function devices.\n\nDisable ASPM and free the pcie_link_state when any child function is\nremoved so we can discard the dangling pcie_link_state-\u0026gt;downstream pointer\nand maintain the same ASPM Control configuration for all functions.\n\n[bhelgaas: commit log and comment](CVE-2023-53446)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Correct devm device reference for hidinput input_dev name\n\nReference the HID device rather than the input device for the devm\nallocation of the input_dev name. Referencing the input_dev would lead to a\nuse-after-free when the input_dev was unregistered and subsequently fires a\nuevent that depends on the name. At the point of firing the uevent, the\nname would be freed by devres management.\n\nUse devm_kasprintf to simplify the logic for allocating memory and\nformatting the input_dev name string.(CVE-2023-53454)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: fix slab-use-after-free in decode_session6\n\nWhen the xfrm device is set to the qdisc of the sfb type, the cb field\nof the sent skb may be modified during enqueuing. Then,\nslab-use-after-free may occur when the xfrm device sends IPv6 packets.\n\nThe stack information is as follows:\nBUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890\nRead of size 1 at addr ffff8881111458ef by task swapper/3/0\nCPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014\nCall Trace:\n\u0026lt;IRQ\u0026gt;\ndump_stack_lvl+0xd9/0x150\nprint_address_description.constprop.0+0x2c/0x3c0\nkasan_report+0x11d/0x130\ndecode_session6+0x103f/0x1890\n__xfrm_decode_session+0x54/0xb0\nxfrmi_xmit+0x173/0x1ca0\ndev_hard_start_xmit+0x187/0x700\nsch_direct_xmit+0x1a3/0xc30\n__qdisc_run+0x510/0x17a0\n__dev_queue_xmit+0x2215/0x3b10\nneigh_connected_output+0x3c2/0x550\nip6_finish_output2+0x55a/0x1550\nip6_finish_output+0x6b9/0x1270\nip6_output+0x1f1/0x540\nndisc_send_skb+0xa63/0x1890\nndisc_send_rs+0x132/0x6f0\naddrconf_rs_timer+0x3f1/0x870\ncall_timer_fn+0x1a0/0x580\nexpire_timers+0x29b/0x4b0\nrun_timer_softirq+0x326/0x910\n__do_softirq+0x1d4/0x905\nirq_exit_rcu+0xb7/0x120\nsysvec_apic_timer_interrupt+0x97/0xc0\n\u0026lt;/IRQ\u0026gt;\n\u0026lt;TASK\u0026gt;\nasm_sysvec_apic_timer_interrupt+0x1a/0x20\nRIP: 0010:intel_idle_hlt+0x23/0x30\nCode: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 \u0026lt;fa\u0026gt; 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4\nRSP: 0018:ffffc90000197d78 EFLAGS: 00000246\nRAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5\nRDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50\nRBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d\nR10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001\nR13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000\ncpuidle_enter_state+0xd3/0x6f0\ncpuidle_enter+0x4e/0xa0\ndo_idle+0x2fe/0x3c0\ncpu_startup_entry+0x18/0x20\nstart_secondary+0x200/0x290\nsecondary_startup_64_no_verify+0x167/0x16b\n\u0026lt;/TASK\u0026gt;\nAllocated by task 939:\nkasan_save_stack+0x22/0x40\nkasan_set_track+0x25/0x30\n__kasan_slab_alloc+0x7f/0x90\nkmem_cache_alloc_node+0x1cd/0x410\nkmalloc_reserve+0x165/0x270\n__alloc_skb+0x129/0x330\ninet6_ifa_notify+0x118/0x230\n__ipv6_ifa_notify+0x177/0xbe0\naddrconf_dad_completed+0x133/0xe00\naddrconf_dad_work+0x764/0x1390\nprocess_one_work+0xa32/0x16f0\nworker_thread+0x67d/0x10c0\nkthread+0x344/0x440\nret_from_fork+0x1f/0x30\nThe buggy address belongs to the object at ffff888111145800\nwhich belongs to the cache skbuff_small_head of size 640\nThe buggy address is located 239 bytes inside of\nfreed 640-byte region [ffff888111145800, ffff888111145a80)\n\nAs commit f855691975bb (\u0026quot;xfrm6: Fix the nexthdr offset in\n_decode_session6.\u0026quot;) showed, xfrm_decode_session was originally intended\nonly for the receive path. IP6CB(skb)-\u0026gt;nhoff is not set during\ntransmission. Therefore, set the cb field in the skb to 0 before\nsending packets.(CVE-2023-53500)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds\n\nFix a stack-out-of-bounds read in brcmfmac that occurs\nwhen \u0026apos;buf\u0026apos; that is not null-terminated is passed as an argument of\nstrreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with\na CLM version string by memcpy() in brcmf_fil_iovar_data_get().\nEnsure buf is null-terminated.\n\nFound by a modified version of syzkaller.\n\n[   33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available\n[   33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22\n[   33.021554][ T1896] ==================================================================\n[   33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110\n[   33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896\n[   33.023852][ T1896]\n[   33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132\n[   33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\n[   33.026065][ T1896] Workqueue: usb_hub_wq hub_event\n[   33.026581][ T1896] Call Trace:\n[   33.026896][ T1896]  dump_stack_lvl+0x57/0x7d\n[   33.027372][ T1896]  print_address_description.constprop.0.cold+0xf/0x334\n[   33.028037][ T1896]  ? strreplace+0xf2/0x110\n[   33.028403][ T1896]  ? strreplace+0xf2/0x110\n[   33.028807][ T1896]  kasan_report.cold+0x83/0xdf\n[   33.029283][ T1896]  ? strreplace+0xf2/0x110\n[   33.029666][ T1896]  strreplace+0xf2/0x110\n[   33.029966][ T1896]  brcmf_c_preinit_dcmds+0xab1/0xc40\n[   33.030351][ T1896]  ? brcmf_c_set_joinpref_default+0x100/0x100\n[   33.030787][ T1896]  ? rcu_read_lock_sched_held+0xa1/0xd0\n[   33.031223][ T1896]  ? rcu_read_lock_bh_held+0xb0/0xb0\n[   33.031661][ T1896]  ? lock_acquire+0x19d/0x4e0\n[   33.032091][ T1896]  ? find_held_lock+0x2d/0x110\n[   33.032605][ T1896]  ? brcmf_usb_deq+0x1a7/0x260\n[   33.033087][ T1896]  ? brcmf_usb_rx_fill_all+0x5a/0xf0\n[   33.033582][ T1896]  brcmf_attach+0x246/0xd40\n[   33.034022][ T1896]  ? wiphy_new_nm+0x1476/0x1d50\n[   33.034383][ T1896]  ? kmemdup+0x30/0x40\n[   33.034722][ T1896]  brcmf_usb_probe+0x12de/0x1690\n[   33.035223][ T1896]  ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n[   33.035833][ T1896]  usb_probe_interface+0x25f/0x710\n[   33.036315][ T1896]  really_probe+0x1be/0xa90\n[   33.036656][ T1896]  __driver_probe_device+0x2ab/0x460\n[   33.037026][ T1896]  ? usb_match_id.part.0+0x88/0xc0\n[   33.037383][ T1896]  driver_probe_device+0x49/0x120\n[   33.037790][ T1896]  __device_attach_driver+0x18a/0x250\n[   33.038300][ T1896]  ? driver_allows_async_probing+0x120/0x120\n[   33.038986][ T1896]  bus_for_each_drv+0x123/0x1a0\n[   33.039906][ T1896]  ? bus_rescan_devices+0x20/0x20\n[   33.041412][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n[   33.041861][ T1896]  ? trace_hardirqs_on+0x1c/0x120\n[   33.042330][ T1896]  __device_attach+0x207/0x330\n[   33.042664][ T1896]  ? device_bind_driver+0xb0/0xb0\n[   33.043026][ T1896]  ? kobject_uevent_env+0x230/0x12c0\n[   33.043515][ T1896]  bus_probe_device+0x1a2/0x260\n[   33.043914][ T1896]  device_add+0xa61/0x1ce0\n[   33.044227][ T1896]  ? __mutex_unlock_slowpath+0xe7/0x660\n[   33.044891][ T1896]  ? __fw_devlink_link_to_suppliers+0x550/0x550\n[   33.045531][ T1896]  usb_set_configuration+0x984/0x1770\n[   33.046051][ T1896]  ? kernfs_create_link+0x175/0x230\n[   33.046548][ T1896]  usb_generic_driver_probe+0x69/0x90\n[   33.046931][ T1896]  usb_probe_device+0x9c/0x220\n[   33.047434][ T1896]  really_probe+0x1be/0xa90\n[   33.047760][ T1896]  __driver_probe_device+0x2ab/0x460\n[   33.048134][ T1896]  driver_probe_device+0x49/0x120\n[   33.048516][ T1896]  __device_attach_driver+0x18a/0x250\n[   33.048910][ T1896]  ? driver_allows_async_probing+0x120/0x120\n---truncated---(CVE-2023-53582)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: hif_usb: fix memory leak of remain_skbs\n\nhif_dev-\u0026gt;remain_skb is allocated and used exclusively in\nath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is\nprocessed and subsequently freed (in error paths) only during the next\ncall of ath9k_hif_usb_rx_stream().\n\nSo, if the urbs are deallocated between those two calls due to the device\ndeinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()\nis not called next time and the allocated remain_skb is leaked. Our local\nSyzkaller instance was able to trigger that.\n\nremain_skb makes sense when receiving two consecutive urbs which are\nlogically linked together, i.e. a specific data field from the first skb\nindicates a cached skb to be allocated, memcpy\u0026apos;d with some data and\nsubsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs\ndeallocation supposedly makes that link irrelevant so we need to free the\ncached skb in those cases.\n\nFix the leak by introducing a function to explicitly free remain_skb (if\nit is not NULL) when the rx urbs have been deallocated. remain_skb is NULL\nwhen it has not been allocated at all (hif_dev struct is kzalloced) or\nwhen it has been processed in next call to ath9k_hif_usb_rx_stream().\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2023-53641)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix possible desc_ptr out-of-bounds accesses\n\nSanitize possible desc_ptr out-of-bounds accesses in\nses_enclosure_data_process().(CVE-2023-53675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()\n\nThe function lio_target_nacl_info_show() uses sprintf() in a loop to print\ndetails for every iSCSI connection in a session without checking for the\nbuffer length. With enough iSCSI connections it\u0026apos;s possible to overflow the\nbuffer provided by configfs and corrupt the memory.\n\nThis patch replaces sprintf() with sysfs_emit_at() that checks for buffer\nboundries.(CVE-2023-53676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()\n\nFix a stack-out-of-bounds write that occurs in a WMI response callback\nfunction that is called after a timeout occurs in ath9k_wmi_cmd().\nThe callback writes to wmi-\u0026gt;cmd_rsp_buf, a stack-allocated buffer that\ncould no longer be valid when a timeout occurs. Set wmi-\u0026gt;last_seq_id to\n0 when a timeout occurred.\n\nFound by a modified version of syzkaller.\n\nBUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rx\nWrite of size 4\nCall Trace:\n memcpy\n ath9k_wmi_ctrl_rx\n ath9k_htc_rx_msg\n ath9k_hif_usb_reg_in_cb\n __usb_hcd_giveback_urb\n usb_hcd_giveback_urb\n dummy_timer\n call_timer_fn\n run_timer_softirq\n __do_softirq\n irq_exit_rcu\n sysvec_apic_timer_interrupt(CVE-2023-53717)\n\nIn the Linux kernel, a resource management vulnerability exists in the cls_u32 network scheduler component. When the u32_replace_hw_knode operation fails, the system fails to properly undo the tcf_bind_filter operation previously performed via u32_set_parms, potentially leading to resource leaks or privilege escalation.(CVE-2023-53733)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u0026gt; trigger BUG_ON due to\n  unmap_poisoned_folio couldn\u0026apos;t\n   handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.(CVE-2025-39782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: udf: fix OOB read in lengthAllocDescs handling\n\nWhen parsing Allocation Extent Descriptor, lengthAllocDescs comes from\non-disk data and must be validated against the block size. Crafted or\ncorrupted images may set lengthAllocDescs so that the total descriptor\nlength (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,\nleading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and\ntrigger a KASAN use-after-free read.\n\nBUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60\nRead of size 1 at addr ffff888041e7d000 by task syz-executor317/5309\n\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60\n udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261\n udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179\n extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46\n udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106\n udf_release_file+0xc1/0x120 fs/udf/file.c:185\n __fput+0x23f/0x880 fs/file_table.c:431\n task_work_run+0x24f/0x310 kernel/task_work.c:239\n exit_task_work include/linux/task_work.h:43 [inline]\n do_exit+0xa2f/0x28e0 kernel/exit.c:939\n do_group_exit+0x207/0x2c0 kernel/exit.c:1088\n __do_sys_exit_group kernel/exit.c:1099 [inline]\n __se_sys_exit_group kernel/exit.c:1097 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097\n x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nValidate the computed total length against epos-\u0026gt;bh-\u0026gt;b_size.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-40044)","status":"published","published":"2025-11-14T11:09:47Z","modified":"2026-08-18T01:19:19.406592967Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:44.957082Z"},{"id":"UBUNTU-CVE-2025-39725","description":"In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list In shrink_folio_list(), the hwpoisoned folio may be large folio, which can't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one() must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then retry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of pvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache. Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough.  memory_failure() will handle it if the UCE is triggered again. This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic.  The race is as follows: cpu0      cpu1  shrink_folio_list memory_failure   TestSetPageHWPoison   unmap_poisoned_folio   --\u003e trigger BUG_ON due to   unmap_poisoned_folio couldn't    handle large folio [tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]","status":"published","published":"2025-09-05T18:15:00Z","modified":"2026-11-11T09:39:05.840310643Z","cvss":[{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-11T10:00:56.786745Z"},{"id":"CVE-2025-39725","title":"mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn't in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u003e trigger BUG_ON due to\n  unmap_poisoned_folio couldn't\n   handle large folio\n\n[tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]","status":"published","published":"2025-09-05T17:27:18.719Z","modified":"2026-10-28T02:30:32.612227984Z","updated_at":"2026-11-02T15:44:49.052395Z"},{"id":"USN-7879-1","title":"linux, linux-aws, linux-gcp, linux-hwe-6.14, linux-oracle, linux-realtime vulnerabilities","description":"It was discovered that improper initialization of CPU cache memory could\nallow a local attacker with hypervisor access to overwrite SEV-SNP guest\nmemory resulting in loss of data integrity. (CVE-2024-36331)\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  - PowerPC architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Network block device driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - Data acquisition framework and drivers;\n  - Hardware crypto device drivers;\n  - Device frequency scaling framework;\n  - DMA engine subsystem;\n  - EDAC drivers;\n  - GPU drivers;\n  - HID subsystem;\n  - Hardware monitoring drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - IIO ADC drivers;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Multiple devices driver;\n  - Media drivers;\n  - Network drivers;\n  - Mellanox network drivers;\n  - PCI subsystem;\n  - PHY drivers;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - Power supply drivers;\n  - Powercap sysfs driver;\n  - Voltage and Current Regulator drivers;\n  - S/390 drivers;\n  - ASPEED SoC drivers;\n  - SPI subsystem;\n  - small TFT LCD display modules;\n  - Media staging drivers;\n  - USB Gadget drivers;\n  - vDPA drivers;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Xen hypervisor drivers;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - EFI Variable file system;\n  - File systems infrastructure;\n  - F2FS file system;\n  - GFS2 file system;\n  - Network file systems library;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - Proc file system;\n  - SMB network file system;\n  - DRM display driver;\n  - io_uring subsystem;\n  - Internal shared memory driver;\n  - padata parallel execution mechanism;\n  - Networking subsytem;\n  - Bluetooth subsystem;\n  - Netfilter;\n  - UDP network protocol;\n  - Tracing infrastructure;\n  - BPF subsystem;\n  - Perf events;\n  - Padata parallel execution mechanism;\n  - Codetag library;\n  - KASAN memory debugging framework;\n  - Memory management;\n  - 802.1Q VLAN protocol;\n  - Appletalk network protocol;\n  - Asynchronous Transfer Mode (ATM) subsystem;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netlink;\n  - RxRPC session sockets;\n  - Network traffic control;\n  - SMC sockets;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - VMware vSockets driver;\n  - Wireless networking;\n  - XFRM subsystem;\n  - ADI SoundPort AD1816A based soundcard drivers;\n  - MediaTek ASoC drivers;\n  - SOF drivers;\n  - USB sound devices;\n  - KVM subsystem;\n(CVE-2025-38335, CVE-2025-38349, CVE-2025-38351, CVE-2025-38437,\nCVE-2025-38438, CVE-2025-38439, CVE-2025-38440, CVE-2025-38441,\nCVE-2025-38443, CVE-2025-38444, CVE-2025-38445, CVE-2025-38446,\nCVE-2025-38448, CVE-2025-38449, CVE-2025-38450, CVE-2025-38451,\nCVE-2025-38452, CVE-2025-38453, CVE-2025-38454, CVE-2025-38455,\nCVE-2025-38456, CVE-2025-38457, CVE-2025-38458, CVE-2025-38459,\nCVE-2025-38460, CVE-2025-38461, CVE-2025-38462, CVE-2025-38463,\nCVE-2025-38464, CVE-2025-38465, CVE-2025-38466, CVE-2025-38467,\nCVE-2025-38468, CVE-2025-38469, CVE-2025-38470, CVE-2025-38471,\nCVE-2025-38472, CVE-2025-38473, CVE-2025-38474, CVE-2025-38475,\nCVE-2025-38476, CVE-2025-38478, CVE-2025-38480, CVE-2025-38481,\nCVE-2025-38482, CVE-2025-38483, CVE-2025-38484, CVE-2025-38485,\nCVE-2025-38487, CVE-2025-38488, CVE-2025-38489, CVE-2025-38490,\nCVE-2025-38491, CVE-2025-38492, CVE-2025-38493, CVE-2025-38494,\nCVE-2025-38495, CVE-2025-38496, CVE-2025-38497, CVE-2025-38501,\nCVE-2025-38503, CVE-2025-38505, CVE-2025-38506, CVE-2025-38507,\nCVE-2025-38508, CVE-2025-38509, CVE-2025-38510, CVE-2025-38511,\nCVE-2025-38512, CVE-2025-38513, CVE-2025-38514, CVE-2025-38515,\nCVE-2025-38516, CVE-2025-38517, CVE-2025-38520, CVE-2025-38521,\nCVE-2025-38524, CVE-2025-38525, CVE-2025-38526, CVE-2025-38527,\nCVE-2025-38528, CVE-2025-38529, CVE-2025-38530, CVE-2025-38531,\nCVE-2025-38532, CVE-2025-38533, CVE-2025-38534, CVE-2025-38535,\nCVE-2025-38537, CVE-2025-38538, CVE-2025-38539, CVE-2025-38540,\nCVE-2025-38542, CVE-2025-38543, CVE-2025-38544, CVE-2025-38545,\nCVE-2025-38546, CVE-2025-38547, CVE-2025-38548, CVE-2025-38549,\nCVE-2025-38550, CVE-2025-38551, CVE-2025-38552, CVE-2025-38553,\nCVE-2025-38555, CVE-2025-38556, CVE-2025-38557, CVE-2025-38558,\nCVE-2025-38559, CVE-2025-38560, CVE-2025-38561, CVE-2025-38562,\nCVE-2025-38563, CVE-2025-38565, CVE-2025-38566, CVE-2025-38567,\nCVE-2025-38568, CVE-2025-38569, CVE-2025-38570, CVE-2025-38571,\nCVE-2025-38572, CVE-2025-38573, CVE-2025-38574, CVE-2025-38576,\nCVE-2025-38577, CVE-2025-38578, CVE-2025-38579, CVE-2025-38581,\nCVE-2025-38582, CVE-2025-38583, CVE-2025-38584, CVE-2025-38585,\nCVE-2025-38586, CVE-2025-38587, CVE-2025-38588, CVE-2025-38589,\nCVE-2025-38590, CVE-2025-38593, CVE-2025-38595, CVE-2025-38601,\nCVE-2025-38602, CVE-2025-38604, CVE-2025-38605, CVE-2025-38606,\nCVE-2025-38608, CVE-2025-38609, CVE-2025-38610, CVE-2025-38612,\nCVE-2025-38615, CVE-2025-38616, CVE-2025-38619, CVE-2025-38622,\nCVE-2025-38623, CVE-2025-38624, CVE-2025-38625, CVE-2025-38626,\nCVE-2025-38628, CVE-2025-38629, CVE-2025-38630, CVE-2025-38631,\nCVE-2025-38632, CVE-2025-38634, CVE-2025-38635, CVE-2025-38639,\nCVE-2025-38640, CVE-2025-38642, CVE-2025-38643, CVE-2025-38644,\nCVE-2025-38645, CVE-2025-38646, CVE-2025-38648, CVE-2025-38649,\nCVE-2025-38650, CVE-2025-38652, CVE-2025-38653, CVE-2025-38654,\nCVE-2025-38655, CVE-2025-38659, CVE-2025-38660, CVE-2025-38662,\nCVE-2025-38663, CVE-2025-38664, CVE-2025-38665, CVE-2025-38666,\nCVE-2025-38668, CVE-2025-38670, CVE-2025-38671, CVE-2025-38675,\nCVE-2025-38678, CVE-2025-39725, CVE-2025-39726, CVE-2025-39727,\nCVE-2025-39730, CVE-2025-39731, CVE-2025-39732, CVE-2025-39734,\nCVE-2025-39809, CVE-2025-39818, CVE-2025-40157)\n","status":"published","published":"2025-11-21T15:26:39Z","modified":"2026-06-03T13:35:25.81509537Z","updated_at":"2026-11-02T16:58:21.91885Z"},{"id":"USN-7879-2","title":"linux-realtime-6.14 vulnerabilities","description":"It was discovered that improper initialization of CPU cache memory could\nallow a local attacker with hypervisor access to overwrite SEV-SNP guest\nmemory resulting in loss of data integrity. (CVE-2024-36331)\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  - PowerPC architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Network block device driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - Data acquisition framework and drivers;\n  - Hardware crypto device drivers;\n  - Device frequency scaling framework;\n  - DMA engine subsystem;\n  - EDAC drivers;\n  - GPU drivers;\n  - HID subsystem;\n  - Hardware monitoring drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - IIO ADC drivers;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Multiple devices driver;\n  - Media drivers;\n  - Network drivers;\n  - Mellanox network drivers;\n  - PCI subsystem;\n  - PHY drivers;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - Power supply drivers;\n  - Powercap sysfs driver;\n  - Voltage and Current Regulator drivers;\n  - S/390 drivers;\n  - ASPEED SoC drivers;\n  - SPI subsystem;\n  - small TFT LCD display modules;\n  - Media staging drivers;\n  - USB Gadget drivers;\n  - vDPA drivers;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Xen hypervisor drivers;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - EFI Variable file system;\n  - File systems infrastructure;\n  - F2FS file system;\n  - GFS2 file system;\n  - Network file systems library;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - Proc file system;\n  - SMB network file system;\n  - DRM display driver;\n  - io_uring subsystem;\n  - Internal shared memory driver;\n  - padata parallel execution mechanism;\n  - Networking subsytem;\n  - Bluetooth subsystem;\n  - Netfilter;\n  - UDP network protocol;\n  - Tracing infrastructure;\n  - BPF subsystem;\n  - Perf events;\n  - Padata parallel execution mechanism;\n  - Codetag library;\n  - KASAN memory debugging framework;\n  - Memory management;\n  - 802.1Q VLAN protocol;\n  - Appletalk network protocol;\n  - Asynchronous Transfer Mode (ATM) subsystem;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netlink;\n  - RxRPC session sockets;\n  - Network traffic control;\n  - SMC sockets;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - VMware vSockets driver;\n  - Wireless networking;\n  - XFRM subsystem;\n  - ADI SoundPort AD1816A based soundcard drivers;\n  - MediaTek ASoC drivers;\n  - SOF drivers;\n  - USB sound devices;\n  - KVM subsystem;\n(CVE-2025-38335, CVE-2025-38349, CVE-2025-38351, CVE-2025-38437,\nCVE-2025-38438, CVE-2025-38439, CVE-2025-38440, CVE-2025-38441,\nCVE-2025-38443, CVE-2025-38444, CVE-2025-38445, CVE-2025-38446,\nCVE-2025-38448, CVE-2025-38449, CVE-2025-38450, CVE-2025-38451,\nCVE-2025-38452, CVE-2025-38453, CVE-2025-38454, CVE-2025-38455,\nCVE-2025-38456, CVE-2025-38457, CVE-2025-38458, CVE-2025-38459,\nCVE-2025-38460, CVE-2025-38461, CVE-2025-38462, CVE-2025-38463,\nCVE-2025-38464, CVE-2025-38465, CVE-2025-38466, CVE-2025-38467,\nCVE-2025-38468, CVE-2025-38469, CVE-2025-38470, CVE-2025-38471,\nCVE-2025-38472, CVE-2025-38473, CVE-2025-38474, CVE-2025-38475,\nCVE-2025-38476, CVE-2025-38478, CVE-2025-38480, CVE-2025-38481,\nCVE-2025-38482, CVE-2025-38483, CVE-2025-38484, CVE-2025-38485,\nCVE-2025-38487, CVE-2025-38488, CVE-2025-38489, CVE-2025-38490,\nCVE-2025-38491, CVE-2025-38492, CVE-2025-38493, CVE-2025-38494,\nCVE-2025-38495, CVE-2025-38496, CVE-2025-38497, CVE-2025-38501,\nCVE-2025-38503, CVE-2025-38505, CVE-2025-38506, CVE-2025-38507,\nCVE-2025-38508, CVE-2025-38509, CVE-2025-38510, CVE-2025-38511,\nCVE-2025-38512, CVE-2025-38513, CVE-2025-38514, CVE-2025-38515,\nCVE-2025-38516, CVE-2025-38517, CVE-2025-38520, CVE-2025-38521,\nCVE-2025-38524, CVE-2025-38525, CVE-2025-38526, CVE-2025-38527,\nCVE-2025-38528, CVE-2025-38529, CVE-2025-38530, CVE-2025-38531,\nCVE-2025-38532, CVE-2025-38533, CVE-2025-38534, CVE-2025-38535,\nCVE-2025-38537, CVE-2025-38538, CVE-2025-38539, CVE-2025-38540,\nCVE-2025-38542, CVE-2025-38543, CVE-2025-38544, CVE-2025-38545,\nCVE-2025-38546, CVE-2025-38547, CVE-2025-38548, CVE-2025-38549,\nCVE-2025-38550, CVE-2025-38551, CVE-2025-38552, CVE-2025-38553,\nCVE-2025-38555, CVE-2025-38556, CVE-2025-38557, CVE-2025-38558,\nCVE-2025-38559, CVE-2025-38560, CVE-2025-38561, CVE-2025-38562,\nCVE-2025-38563, CVE-2025-38565, CVE-2025-38566, CVE-2025-38567,\nCVE-2025-38568, CVE-2025-38569, CVE-2025-38570, CVE-2025-38571,\nCVE-2025-38572, CVE-2025-38573, CVE-2025-38574, CVE-2025-38576,\nCVE-2025-38577, CVE-2025-38578, CVE-2025-38579, CVE-2025-38581,\nCVE-2025-38582, CVE-2025-38583, CVE-2025-38584, CVE-2025-38585,\nCVE-2025-38586, CVE-2025-38587, CVE-2025-38588, CVE-2025-38589,\nCVE-2025-38590, CVE-2025-38593, CVE-2025-38595, CVE-2025-38601,\nCVE-2025-38602, CVE-2025-38604, CVE-2025-38605, CVE-2025-38606,\nCVE-2025-38608, CVE-2025-38609, CVE-2025-38610, CVE-2025-38612,\nCVE-2025-38615, CVE-2025-38616, CVE-2025-38619, CVE-2025-38622,\nCVE-2025-38623, CVE-2025-38624, CVE-2025-38625, CVE-2025-38626,\nCVE-2025-38628, CVE-2025-38629, CVE-2025-38630, CVE-2025-38631,\nCVE-2025-38632, CVE-2025-38634, CVE-2025-38635, CVE-2025-38639,\nCVE-2025-38640, CVE-2025-38642, CVE-2025-38643, CVE-2025-38644,\nCVE-2025-38645, CVE-2025-38646, CVE-2025-38648, CVE-2025-38649,\nCVE-2025-38650, CVE-2025-38652, CVE-2025-38653, CVE-2025-38654,\nCVE-2025-38655, CVE-2025-38659, CVE-2025-38660, CVE-2025-38662,\nCVE-2025-38663, CVE-2025-38664, CVE-2025-38665, CVE-2025-38666,\nCVE-2025-38668, CVE-2025-38670, CVE-2025-38671, CVE-2025-38675,\nCVE-2025-38678, CVE-2025-39725, CVE-2025-39726, CVE-2025-39727,\nCVE-2025-39730, CVE-2025-39731, CVE-2025-39732, CVE-2025-39734,\nCVE-2025-39809, CVE-2025-39818, CVE-2025-40157)\n","status":"published","published":"2025-11-21T15:45:02Z","modified":"2026-11-03T14:33:58.968823468Z","updated_at":"2026-11-03T15:17:16.577329Z"},{"id":"USN-7879-3","title":"linux-aws-6.14, linux-oracle-6.14 vulnerabilities","description":"It was discovered that improper initialization of CPU cache memory could\nallow a local attacker with hypervisor access to overwrite SEV-SNP guest\nmemory resulting in loss of data integrity. (CVE-2024-36331)\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  - PowerPC architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Network block device driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - Data acquisition framework and drivers;\n  - Hardware crypto device drivers;\n  - Device frequency scaling framework;\n  - DMA engine subsystem;\n  - EDAC drivers;\n  - GPU drivers;\n  - HID subsystem;\n  - Hardware monitoring drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - IIO ADC drivers;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Multiple devices driver;\n  - Media drivers;\n  - Network drivers;\n  - Mellanox network drivers;\n  - PCI subsystem;\n  - PHY drivers;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - Power supply drivers;\n  - Powercap sysfs driver;\n  - Voltage and Current Regulator drivers;\n  - S/390 drivers;\n  - ASPEED SoC drivers;\n  - SPI subsystem;\n  - small TFT LCD display modules;\n  - Media staging drivers;\n  - USB Gadget drivers;\n  - vDPA drivers;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Xen hypervisor drivers;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - EFI Variable file system;\n  - File systems infrastructure;\n  - F2FS file system;\n  - GFS2 file system;\n  - Network file systems library;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - Proc file system;\n  - SMB network file system;\n  - DRM display driver;\n  - io_uring subsystem;\n  - Internal shared memory driver;\n  - padata parallel execution mechanism;\n  - Networking subsytem;\n  - Bluetooth subsystem;\n  - Netfilter;\n  - UDP network protocol;\n  - Tracing infrastructure;\n  - BPF subsystem;\n  - Perf events;\n  - Padata parallel execution mechanism;\n  - Codetag library;\n  - KASAN memory debugging framework;\n  - Memory management;\n  - 802.1Q VLAN protocol;\n  - Appletalk network protocol;\n  - Asynchronous Transfer Mode (ATM) subsystem;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netlink;\n  - RxRPC session sockets;\n  - Network traffic control;\n  - SMC sockets;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - VMware vSockets driver;\n  - Wireless networking;\n  - XFRM subsystem;\n  - ADI SoundPort AD1816A based soundcard drivers;\n  - MediaTek ASoC drivers;\n  - SOF drivers;\n  - USB sound devices;\n  - KVM subsystem;\n(CVE-2025-38335, CVE-2025-38349, CVE-2025-38351, CVE-2025-38437,\nCVE-2025-38438, CVE-2025-38439, CVE-2025-38440, CVE-2025-38441,\nCVE-2025-38443, CVE-2025-38444, CVE-2025-38445, CVE-2025-38446,\nCVE-2025-38448, CVE-2025-38449, CVE-2025-38450, CVE-2025-38451,\nCVE-2025-38452, CVE-2025-38453, CVE-2025-38454, CVE-2025-38455,\nCVE-2025-38456, CVE-2025-38457, CVE-2025-38458, CVE-2025-38459,\nCVE-2025-38460, CVE-2025-38461, CVE-2025-38462, CVE-2025-38463,\nCVE-2025-38464, CVE-2025-38465, CVE-2025-38466, CVE-2025-38467,\nCVE-2025-38468, CVE-2025-38469, CVE-2025-38470, CVE-2025-38471,\nCVE-2025-38472, CVE-2025-38473, CVE-2025-38474, CVE-2025-38475,\nCVE-2025-38476, CVE-2025-38478, CVE-2025-38480, CVE-2025-38481,\nCVE-2025-38482, CVE-2025-38483, CVE-2025-38484, CVE-2025-38485,\nCVE-2025-38487, CVE-2025-38488, CVE-2025-38489, CVE-2025-38490,\nCVE-2025-38491, CVE-2025-38492, CVE-2025-38493, CVE-2025-38494,\nCVE-2025-38495, CVE-2025-38496, CVE-2025-38497, CVE-2025-38501,\nCVE-2025-38503, CVE-2025-38505, CVE-2025-38506, CVE-2025-38507,\nCVE-2025-38508, CVE-2025-38509, CVE-2025-38510, CVE-2025-38511,\nCVE-2025-38512, CVE-2025-38513, CVE-2025-38514, CVE-2025-38515,\nCVE-2025-38516, CVE-2025-38517, CVE-2025-38520, CVE-2025-38521,\nCVE-2025-38524, CVE-2025-38525, CVE-2025-38526, CVE-2025-38527,\nCVE-2025-38528, CVE-2025-38529, CVE-2025-38530, CVE-2025-38531,\nCVE-2025-38532, CVE-2025-38533, CVE-2025-38534, CVE-2025-38535,\nCVE-2025-38537, CVE-2025-38538, CVE-2025-38539, CVE-2025-38540,\nCVE-2025-38542, CVE-2025-38543, CVE-2025-38544, CVE-2025-38545,\nCVE-2025-38546, CVE-2025-38547, CVE-2025-38548, CVE-2025-38549,\nCVE-2025-38550, CVE-2025-38551, CVE-2025-38552, CVE-2025-38553,\nCVE-2025-38555, CVE-2025-38556, CVE-2025-38557, CVE-2025-38558,\nCVE-2025-38559, CVE-2025-38560, CVE-2025-38561, CVE-2025-38562,\nCVE-2025-38563, CVE-2025-38565, CVE-2025-38566, CVE-2025-38567,\nCVE-2025-38568, CVE-2025-38569, CVE-2025-38570, CVE-2025-38571,\nCVE-2025-38572, CVE-2025-38573, CVE-2025-38574, CVE-2025-38576,\nCVE-2025-38577, CVE-2025-38578, CVE-2025-38579, CVE-2025-38581,\nCVE-2025-38582, CVE-2025-38583, CVE-2025-38584, CVE-2025-38585,\nCVE-2025-38586, CVE-2025-38587, CVE-2025-38588, CVE-2025-38589,\nCVE-2025-38590, CVE-2025-38593, CVE-2025-38595, CVE-2025-38601,\nCVE-2025-38602, CVE-2025-38604, CVE-2025-38605, CVE-2025-38606,\nCVE-2025-38608, CVE-2025-38609, CVE-2025-38610, CVE-2025-38612,\nCVE-2025-38615, CVE-2025-38616, CVE-2025-38619, CVE-2025-38622,\nCVE-2025-38623, CVE-2025-38624, CVE-2025-38625, CVE-2025-38626,\nCVE-2025-38628, CVE-2025-38629, CVE-2025-38630, CVE-2025-38631,\nCVE-2025-38632, CVE-2025-38634, CVE-2025-38635, CVE-2025-38639,\nCVE-2025-38640, CVE-2025-38642, CVE-2025-38643, CVE-2025-38644,\nCVE-2025-38645, CVE-2025-38646, CVE-2025-38648, CVE-2025-38649,\nCVE-2025-38650, CVE-2025-38652, CVE-2025-38653, CVE-2025-38654,\nCVE-2025-38655, CVE-2025-38659, CVE-2025-38660, CVE-2025-38662,\nCVE-2025-38663, CVE-2025-38664, CVE-2025-38665, CVE-2025-38666,\nCVE-2025-38668, CVE-2025-38670, CVE-2025-38671, CVE-2025-38675,\nCVE-2025-38678, CVE-2025-39725, CVE-2025-39726, CVE-2025-39727,\nCVE-2025-39730, CVE-2025-39731, CVE-2025-39732, CVE-2025-39734,\nCVE-2025-39809, CVE-2025-39818, CVE-2025-40157)\n","status":"published","published":"2025-11-26T08:34:26Z","modified":"2026-11-03T14:34:02.86690422Z","updated_at":"2026-11-03T15:17:16.577329Z"},{"id":"USN-7879-4","title":"linux-gcp-6.14, linux-raspi vulnerabilities","description":"It was discovered that improper initialization of CPU cache memory could\nallow a local attacker with hypervisor access to overwrite SEV-SNP guest\nmemory resulting in loss of data integrity. (CVE-2024-36331)\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  - PowerPC architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Network block device driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - Data acquisition framework and drivers;\n  - Hardware crypto device drivers;\n  - Device frequency scaling framework;\n  - DMA engine subsystem;\n  - EDAC drivers;\n  - GPU drivers;\n  - HID subsystem;\n  - Hardware monitoring drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - IIO ADC drivers;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Multiple devices driver;\n  - Media drivers;\n  - Network drivers;\n  - Mellanox network drivers;\n  - PCI subsystem;\n  - PHY drivers;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - Power supply drivers;\n  - Powercap sysfs driver;\n  - Voltage and Current Regulator drivers;\n  - S/390 drivers;\n  - ASPEED SoC drivers;\n  - SPI subsystem;\n  - small TFT LCD display modules;\n  - Media staging drivers;\n  - USB Gadget drivers;\n  - vDPA drivers;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Xen hypervisor drivers;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - EFI Variable file system;\n  - File systems infrastructure;\n  - F2FS file system;\n  - GFS2 file system;\n  - Network file systems library;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - Proc file system;\n  - SMB network file system;\n  - DRM display driver;\n  - io_uring subsystem;\n  - Internal shared memory driver;\n  - padata parallel execution mechanism;\n  - Networking subsytem;\n  - Bluetooth subsystem;\n  - Netfilter;\n  - UDP network protocol;\n  - Tracing infrastructure;\n  - BPF subsystem;\n  - Perf events;\n  - Padata parallel execution mechanism;\n  - Codetag library;\n  - KASAN memory debugging framework;\n  - Memory management;\n  - 802.1Q VLAN protocol;\n  - Appletalk network protocol;\n  - Asynchronous Transfer Mode (ATM) subsystem;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netlink;\n  - RxRPC session sockets;\n  - Network traffic control;\n  - SMC sockets;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - VMware vSockets driver;\n  - Wireless networking;\n  - XFRM subsystem;\n  - ADI SoundPort AD1816A based soundcard drivers;\n  - MediaTek ASoC drivers;\n  - SOF drivers;\n  - USB sound devices;\n  - KVM subsystem;\n(CVE-2025-38335, CVE-2025-38349, CVE-2025-38351, CVE-2025-38437,\nCVE-2025-38438, CVE-2025-38439, CVE-2025-38440, CVE-2025-38441,\nCVE-2025-38443, CVE-2025-38444, CVE-2025-38445, CVE-2025-38446,\nCVE-2025-38448, CVE-2025-38449, CVE-2025-38450, CVE-2025-38451,\nCVE-2025-38452, CVE-2025-38453, CVE-2025-38454, CVE-2025-38455,\nCVE-2025-38456, CVE-2025-38457, CVE-2025-38458, CVE-2025-38459,\nCVE-2025-38460, CVE-2025-38461, CVE-2025-38462, CVE-2025-38463,\nCVE-2025-38464, CVE-2025-38465, CVE-2025-38466, CVE-2025-38467,\nCVE-2025-38468, CVE-2025-38469, CVE-2025-38470, CVE-2025-38471,\nCVE-2025-38472, CVE-2025-38473, CVE-2025-38474, CVE-2025-38475,\nCVE-2025-38476, CVE-2025-38478, CVE-2025-38480, CVE-2025-38481,\nCVE-2025-38482, CVE-2025-38483, CVE-2025-38484, CVE-2025-38485,\nCVE-2025-38487, CVE-2025-38488, CVE-2025-38489, CVE-2025-38490,\nCVE-2025-38491, CVE-2025-38492, CVE-2025-38493, CVE-2025-38494,\nCVE-2025-38495, CVE-2025-38496, CVE-2025-38497, CVE-2025-38501,\nCVE-2025-38503, CVE-2025-38505, CVE-2025-38506, CVE-2025-38507,\nCVE-2025-38508, CVE-2025-38509, CVE-2025-38510, CVE-2025-38511,\nCVE-2025-38512, CVE-2025-38513, CVE-2025-38514, CVE-2025-38515,\nCVE-2025-38516, CVE-2025-38517, CVE-2025-38520, CVE-2025-38521,\nCVE-2025-38524, CVE-2025-38525, CVE-2025-38526, CVE-2025-38527,\nCVE-2025-38528, CVE-2025-38529, CVE-2025-38530, CVE-2025-38531,\nCVE-2025-38532, CVE-2025-38533, CVE-2025-38534, CVE-2025-38535,\nCVE-2025-38537, CVE-2025-38538, CVE-2025-38539, CVE-2025-38540,\nCVE-2025-38542, CVE-2025-38543, CVE-2025-38544, CVE-2025-38545,\nCVE-2025-38546, CVE-2025-38547, CVE-2025-38548, CVE-2025-38549,\nCVE-2025-38550, CVE-2025-38551, CVE-2025-38552, CVE-2025-38553,\nCVE-2025-38555, CVE-2025-38556, CVE-2025-38557, CVE-2025-38558,\nCVE-2025-38559, CVE-2025-38560, CVE-2025-38561, CVE-2025-38562,\nCVE-2025-38563, CVE-2025-38565, CVE-2025-38566, CVE-2025-38567,\nCVE-2025-38568, CVE-2025-38569, CVE-2025-38570, CVE-2025-38571,\nCVE-2025-38572, CVE-2025-38573, CVE-2025-38574, CVE-2025-38576,\nCVE-2025-38577, CVE-2025-38578, CVE-2025-38579, CVE-2025-38581,\nCVE-2025-38582, CVE-2025-38583, CVE-2025-38584, CVE-2025-38585,\nCVE-2025-38586, CVE-2025-38587, CVE-2025-38588, CVE-2025-38589,\nCVE-2025-38590, CVE-2025-38593, CVE-2025-38595, CVE-2025-38601,\nCVE-2025-38602, CVE-2025-38604, CVE-2025-38605, CVE-2025-38606,\nCVE-2025-38608, CVE-2025-38609, CVE-2025-38610, CVE-2025-38612,\nCVE-2025-38615, CVE-2025-38616, CVE-2025-38619, CVE-2025-38622,\nCVE-2025-38623, CVE-2025-38624, CVE-2025-38625, CVE-2025-38626,\nCVE-2025-38628, CVE-2025-38629, CVE-2025-38630, CVE-2025-38631,\nCVE-2025-38632, CVE-2025-38634, CVE-2025-38635, CVE-2025-38639,\nCVE-2025-38640, CVE-2025-38642, CVE-2025-38643, CVE-2025-38644,\nCVE-2025-38645, CVE-2025-38646, CVE-2025-38648, CVE-2025-38649,\nCVE-2025-38650, CVE-2025-38652, CVE-2025-38653, CVE-2025-38654,\nCVE-2025-38655, CVE-2025-38659, CVE-2025-38660, CVE-2025-38662,\nCVE-2025-38663, CVE-2025-38664, CVE-2025-38665, CVE-2025-38666,\nCVE-2025-38668, CVE-2025-38670, CVE-2025-38671, CVE-2025-38675,\nCVE-2025-38678, CVE-2025-39725, CVE-2025-39726, CVE-2025-39727,\nCVE-2025-39730, CVE-2025-39731, CVE-2025-39732, CVE-2025-39734,\nCVE-2025-39809, CVE-2025-39818, CVE-2025-40157)\n","status":"published","published":"2025-12-04T10:22:14Z","modified":"2026-11-03T14:34:04.402703108Z","updated_at":"2026-11-03T15:17:11.325641Z"},{"id":"USN-7880-1","title":"linux-oem-6.14 vulnerabilities","description":"It was discovered that improper initialization of CPU cache memory could\nallow a local attacker with hypervisor access to overwrite SEV-SNP guest\nmemory resulting in loss of data integrity. (CVE-2024-36331)\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  - PowerPC architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Network block device driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - Data acquisition framework and drivers;\n  - Hardware crypto device drivers;\n  - Device frequency scaling framework;\n  - DMA engine subsystem;\n  - GPU drivers;\n  - HID subsystem;\n  - Hardware monitoring drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - IIO ADC drivers;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Multiple devices driver;\n  - Media drivers;\n  - Network drivers;\n  - Mellanox network drivers;\n  - PCI subsystem;\n  - PHY drivers;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - Power supply drivers;\n  - Powercap sysfs driver;\n  - Voltage and Current Regulator drivers;\n  - S/390 drivers;\n  - ASPEED SoC drivers;\n  - SPI subsystem;\n  - small TFT LCD display modules;\n  - Media staging drivers;\n  - USB Gadget drivers;\n  - vDPA drivers;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Xen hypervisor drivers;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - EFI Variable file system;\n  - File systems infrastructure;\n  - F2FS file system;\n  - GFS2 file system;\n  - Network file systems library;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - Proc file system;\n  - SMB network file system;\n  - DRM display driver;\n  - io_uring subsystem;\n  - Internal shared memory driver;\n  - padata parallel execution mechanism;\n  - Networking subsytem;\n  - Bluetooth subsystem;\n  - Netfilter;\n  - UDP network protocol;\n  - Tracing infrastructure;\n  - BPF subsystem;\n  - Perf events;\n  - Padata parallel execution mechanism;\n  - Codetag library;\n  - KASAN memory debugging framework;\n  - Memory management;\n  - 802.1Q VLAN protocol;\n  - Appletalk network protocol;\n  - Asynchronous Transfer Mode (ATM) subsystem;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netlink;\n  - RxRPC session sockets;\n  - Network traffic control;\n  - SMC sockets;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - VMware vSockets driver;\n  - Wireless networking;\n  - XFRM subsystem;\n  - ADI SoundPort AD1816A based soundcard drivers;\n  - MediaTek ASoC drivers;\n  - SOF drivers;\n  - USB sound devices;\n  - KVM subsystem;\n(CVE-2025-38335, CVE-2025-38349, CVE-2025-38351, CVE-2025-38437,\nCVE-2025-38438, CVE-2025-38439, CVE-2025-38440, CVE-2025-38441,\nCVE-2025-38443, CVE-2025-38444, CVE-2025-38445, CVE-2025-38446,\nCVE-2025-38448, CVE-2025-38449, CVE-2025-38450, CVE-2025-38451,\nCVE-2025-38452, CVE-2025-38453, CVE-2025-38454, CVE-2025-38455,\nCVE-2025-38456, CVE-2025-38457, CVE-2025-38458, CVE-2025-38459,\nCVE-2025-38460, CVE-2025-38461, CVE-2025-38462, CVE-2025-38463,\nCVE-2025-38464, CVE-2025-38465, CVE-2025-38466, CVE-2025-38467,\nCVE-2025-38468, CVE-2025-38469, CVE-2025-38470, CVE-2025-38471,\nCVE-2025-38472, CVE-2025-38473, CVE-2025-38474, CVE-2025-38475,\nCVE-2025-38476, CVE-2025-38478, CVE-2025-38480, CVE-2025-38481,\nCVE-2025-38482, CVE-2025-38483, CVE-2025-38484, CVE-2025-38485,\nCVE-2025-38487, CVE-2025-38488, CVE-2025-38489, CVE-2025-38490,\nCVE-2025-38491, CVE-2025-38492, CVE-2025-38493, CVE-2025-38494,\nCVE-2025-38495, CVE-2025-38496, CVE-2025-38497, CVE-2025-38501,\nCVE-2025-38503, CVE-2025-38505, CVE-2025-38506, CVE-2025-38507,\nCVE-2025-38508, CVE-2025-38509, CVE-2025-38510, CVE-2025-38511,\nCVE-2025-38512, CVE-2025-38513, CVE-2025-38514, CVE-2025-38515,\nCVE-2025-38516, CVE-2025-38517, CVE-2025-38520, CVE-2025-38521,\nCVE-2025-38524, CVE-2025-38525, CVE-2025-38526, CVE-2025-38527,\nCVE-2025-38528, CVE-2025-38529, CVE-2025-38530, CVE-2025-38531,\nCVE-2025-38532, CVE-2025-38533, CVE-2025-38534, CVE-2025-38535,\nCVE-2025-38537, CVE-2025-38538, CVE-2025-38539, CVE-2025-38540,\nCVE-2025-38542, CVE-2025-38543, CVE-2025-38544, CVE-2025-38545,\nCVE-2025-38546, CVE-2025-38547, CVE-2025-38548, CVE-2025-38549,\nCVE-2025-38550, CVE-2025-38551, CVE-2025-38552, CVE-2025-38553,\nCVE-2025-38555, CVE-2025-38556, CVE-2025-38557, CVE-2025-38558,\nCVE-2025-38559, CVE-2025-38560, CVE-2025-38561, CVE-2025-38562,\nCVE-2025-38563, CVE-2025-38565, CVE-2025-38566, CVE-2025-38567,\nCVE-2025-38568, CVE-2025-38569, CVE-2025-38570, CVE-2025-38571,\nCVE-2025-38572, CVE-2025-38573, CVE-2025-38574, CVE-2025-38576,\nCVE-2025-38577, CVE-2025-38578, CVE-2025-38579, CVE-2025-38581,\nCVE-2025-38582, CVE-2025-38583, CVE-2025-38584, CVE-2025-38585,\nCVE-2025-38586, CVE-2025-38587, CVE-2025-38588, CVE-2025-38589,\nCVE-2025-38590, CVE-2025-38593, CVE-2025-38595, CVE-2025-38601,\nCVE-2025-38602, CVE-2025-38604, CVE-2025-38605, CVE-2025-38606,\nCVE-2025-38608, CVE-2025-38609, CVE-2025-38610, CVE-2025-38612,\nCVE-2025-38615, CVE-2025-38616, CVE-2025-38619, CVE-2025-38622,\nCVE-2025-38623, CVE-2025-38624, CVE-2025-38625, CVE-2025-38626,\nCVE-2025-38628, CVE-2025-38629, CVE-2025-38630, CVE-2025-38631,\nCVE-2025-38632, CVE-2025-38634, CVE-2025-38635, CVE-2025-38639,\nCVE-2025-38640, CVE-2025-38642, CVE-2025-38643, CVE-2025-38644,\nCVE-2025-38645, CVE-2025-38646, CVE-2025-38648, CVE-2025-38649,\nCVE-2025-38650, CVE-2025-38652, CVE-2025-38653, CVE-2025-38654,\nCVE-2025-38655, CVE-2025-38659, CVE-2025-38660, CVE-2025-38662,\nCVE-2025-38663, CVE-2025-38664, CVE-2025-38665, CVE-2025-38666,\nCVE-2025-38668, CVE-2025-38670, CVE-2025-38671, CVE-2025-38675,\nCVE-2025-38678, CVE-2025-39725, CVE-2025-39726, CVE-2025-39727,\nCVE-2025-39730, CVE-2025-39731, CVE-2025-39732, CVE-2025-39734)\n","status":"published","published":"2025-11-21T15:57:32Z","modified":"2026-11-03T14:34:00.62137189Z","updated_at":"2026-11-03T15:17:16.577329Z"},{"id":"USN-7934-1","title":"linux-azure, linux-azure-6.14 vulnerabilities","description":"It was discovered that improper initialization of CPU cache memory could\nallow a local attacker with hypervisor access to overwrite SEV-SNP guest\nmemory resulting in loss of data integrity. (CVE-2024-36331)\n\nJean-Claude Graf, Sandro Rüegge, Ali Hajiabadi, and Kaveh Razavi discovered\nthat the Linux kernel contained insufficient branch predictor isolation\nbetween a guest and a userspace hypervisor for certain processors. This\nflaw is known as VMSCAPE. An attacker in a guest VM could possibly use this\nto expose sensitive information from the host OS. (CVE-2025-40300)\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  - PowerPC architecture;\n  - S390 architecture;\n  - x86 architecture;\n  - Cryptographic API;\n  - Network block device driver;\n  - Character device driver;\n  - Clock framework and drivers;\n  - Data acquisition framework and drivers;\n  - Hardware crypto device drivers;\n  - Device frequency scaling framework;\n  - DMA engine subsystem;\n  - EDAC drivers;\n  - GPU drivers;\n  - HID subsystem;\n  - Hardware monitoring drivers;\n  - I2C subsystem;\n  - IIO subsystem;\n  - IIO ADC drivers;\n  - InfiniBand drivers;\n  - Input Device core drivers;\n  - Multiple devices driver;\n  - Media drivers;\n  - Network drivers;\n  - Mellanox network drivers;\n  - PCI subsystem;\n  - PHY drivers;\n  - Pin controllers subsystem;\n  - x86 platform drivers;\n  - Power supply drivers;\n  - Powercap sysfs driver;\n  - Voltage and Current Regulator drivers;\n  - S/390 drivers;\n  - ASPEED SoC drivers;\n  - SPI subsystem;\n  - small TFT LCD display modules;\n  - Media staging drivers;\n  - USB Gadget drivers;\n  - vDPA drivers;\n  - VFIO drivers;\n  - Framebuffer layer;\n  - Xen hypervisor drivers;\n  - BTRFS file system;\n  - Ceph distributed file system;\n  - EFI Variable file system;\n  - File systems infrastructure;\n  - F2FS file system;\n  - GFS2 file system;\n  - Network file systems library;\n  - Network file system (NFS) client;\n  - Network file system (NFS) server daemon;\n  - NILFS2 file system;\n  - NTFS3 file system;\n  - Proc file system;\n  - SMB network file system;\n  - DRM display driver;\n  - io_uring subsystem;\n  - Internal shared memory driver;\n  - padata parallel execution mechanism;\n  - Networking subsytem;\n  - Bluetooth subsystem;\n  - Netfilter;\n  - UDP network protocol;\n  - Tracing infrastructure;\n  - BPF subsystem;\n  - Perf events;\n  - Padata parallel execution mechanism;\n  - Codetag library;\n  - KASAN memory debugging framework;\n  - Memory management;\n  - 802.1Q VLAN protocol;\n  - Appletalk network protocol;\n  - Asynchronous Transfer Mode (ATM) subsystem;\n  - Networking core;\n  - IPv4 networking;\n  - IPv6 networking;\n  - MAC80211 subsystem;\n  - Multipath TCP;\n  - Netlink;\n  - RxRPC session sockets;\n  - Network traffic control;\n  - SMC sockets;\n  - Sun RPC protocol;\n  - TIPC protocol;\n  - TLS protocol;\n  - VMware vSockets driver;\n  - Wireless networking;\n  - XFRM subsystem;\n  - ADI SoundPort AD1816A based soundcard drivers;\n  - MediaTek ASoC drivers;\n  - SOF drivers;\n  - USB sound devices;\n  - KVM subsystem;\n(CVE-2025-38335, CVE-2025-38349, CVE-2025-38351, CVE-2025-38437,\nCVE-2025-38438, CVE-2025-38439, CVE-2025-38440, CVE-2025-38441,\nCVE-2025-38443, CVE-2025-38444, CVE-2025-38445, CVE-2025-38446,\nCVE-2025-38448, CVE-2025-38449, CVE-2025-38450, CVE-2025-38451,\nCVE-2025-38452, CVE-2025-38453, CVE-2025-38454, CVE-2025-38455,\nCVE-2025-38456, CVE-2025-38457, CVE-2025-38458, CVE-2025-38459,\nCVE-2025-38460, CVE-2025-38461, CVE-2025-38462, CVE-2025-38463,\nCVE-2025-38464, CVE-2025-38465, CVE-2025-38466, CVE-2025-38467,\nCVE-2025-38468, CVE-2025-38469, CVE-2025-38470, CVE-2025-38471,\nCVE-2025-38472, CVE-2025-38473, CVE-2025-38474, CVE-2025-38475,\nCVE-2025-38476, CVE-2025-38478, CVE-2025-38480, CVE-2025-38481,\nCVE-2025-38482, CVE-2025-38483, CVE-2025-38484, CVE-2025-38485,\nCVE-2025-38487, CVE-2025-38488, CVE-2025-38489, CVE-2025-38490,\nCVE-2025-38491, CVE-2025-38492, CVE-2025-38493, CVE-2025-38494,\nCVE-2025-38495, CVE-2025-38496, CVE-2025-38497, CVE-2025-38501,\nCVE-2025-38503, CVE-2025-38505, CVE-2025-38506, CVE-2025-38507,\nCVE-2025-38508, CVE-2025-38509, CVE-2025-38510, CVE-2025-38511,\nCVE-2025-38512, CVE-2025-38513, CVE-2025-38514, CVE-2025-38515,\nCVE-2025-38516, CVE-2025-38517, CVE-2025-38520, CVE-2025-38521,\nCVE-2025-38524, CVE-2025-38525, CVE-2025-38526, CVE-2025-38527,\nCVE-2025-38528, CVE-2025-38529, CVE-2025-38530, CVE-2025-38531,\nCVE-2025-38532, CVE-2025-38533, CVE-2025-38534, CVE-2025-38535,\nCVE-2025-38537, CVE-2025-38538, CVE-2025-38539, CVE-2025-38540,\nCVE-2025-38542, CVE-2025-38543, CVE-2025-38544, CVE-2025-38545,\nCVE-2025-38546, CVE-2025-38547, CVE-2025-38548, CVE-2025-38549,\nCVE-2025-38550, CVE-2025-38551, CVE-2025-38552, CVE-2025-38553,\nCVE-2025-38555, CVE-2025-38556, CVE-2025-38557, CVE-2025-38558,\nCVE-2025-38559, CVE-2025-38560, CVE-2025-38561, CVE-2025-38562,\nCVE-2025-38563, CVE-2025-38565, CVE-2025-38566, CVE-2025-38567,\nCVE-2025-38568, CVE-2025-38569, CVE-2025-38570, CVE-2025-38571,\nCVE-2025-38572, CVE-2025-38573, CVE-2025-38574, CVE-2025-38576,\nCVE-2025-38577, CVE-2025-38578, CVE-2025-38579, CVE-2025-38581,\nCVE-2025-38582, CVE-2025-38583, CVE-2025-38584, CVE-2025-38585,\nCVE-2025-38586, CVE-2025-38587, CVE-2025-38588, CVE-2025-38589,\nCVE-2025-38590, CVE-2025-38593, CVE-2025-38595, CVE-2025-38601,\nCVE-2025-38602, CVE-2025-38604, CVE-2025-38605, CVE-2025-38606,\nCVE-2025-38608, CVE-2025-38609, CVE-2025-38610, CVE-2025-38612,\nCVE-2025-38615, CVE-2025-38616, CVE-2025-38619, CVE-2025-38622,\nCVE-2025-38623, CVE-2025-38624, CVE-2025-38625, CVE-2025-38626,\nCVE-2025-38628, CVE-2025-38629, CVE-2025-38630, CVE-2025-38631,\nCVE-2025-38632, CVE-2025-38634, CVE-2025-38635, CVE-2025-38639,\nCVE-2025-38640, CVE-2025-38642, CVE-2025-38643, CVE-2025-38644,\nCVE-2025-38645, CVE-2025-38646, CVE-2025-38648, CVE-2025-38649,\nCVE-2025-38650, CVE-2025-38652, CVE-2025-38653, CVE-2025-38654,\nCVE-2025-38655, CVE-2025-38659, CVE-2025-38660, CVE-2025-38662,\nCVE-2025-38663, CVE-2025-38664, CVE-2025-38665, CVE-2025-38666,\nCVE-2025-38668, CVE-2025-38670, CVE-2025-38671, CVE-2025-38675,\nCVE-2025-38678, CVE-2025-39725, CVE-2025-39726, CVE-2025-39727,\nCVE-2025-39730, CVE-2025-39731, CVE-2025-39732, CVE-2025-39734,\nCVE-2025-39809, CVE-2025-39818, CVE-2025-39946, CVE-2025-39964,\nCVE-2025-39993, CVE-2025-40018, CVE-2025-40157)\n","status":"published","published":"2025-12-15T20:51:05Z","modified":"2026-11-03T14:34:22.418957954Z","updated_at":"2026-11-03T15:17:04.783338Z"}]}}