Debian published DSA-6528-1, a Linux kernel update covering hundreds of CVEs.
Debian Security Advisory DSA-6528-1, sent by Salvatore Bonaccorso on 29 September 2026, says several vulnerabilities were discovered in the Linux kernel. The notice lists hundreds of CVE identifiers from 2024, 2025, and 2026 against the Debian linux package. It does not state that any flaw is being exploited or give individual severity ratings. The excerpt is truncated, so the CVE list shown is incomplete.
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
CVE-2024-52560+1 related CVE | Linux kernel: fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr() Extended the `mi_enum_attr()`… In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr() Extended the `mi_enum_attr()` function interface with an additional parameter, `struct ntfs_inode *ni`, to allow marking the inode as bad as soon as an error is detected. NVD description · AI analysis pending | 5.5 | <1% |
| — | ||
CVE-2025-22104+4 related CVEs |
| From: | Salvatore Bonaccorso <carnil@debian.org> | |
| To: | debian-security-announce@lists.debian.org | |
| Subject: | [SECURITY] [DSA 6528-1] linux security update | |
| Date: | Tue, 29 Sep 2026 09:49:30 +0000 | |
| Message-ID: | <E1xBUSo-0000000F7rk-1P79@seger.debian.org> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 - ------------------------------------------------------------------------- Debian Security Advisory DSA-6528-1 security@debian.org https://www.debian.org/security/ Salvatore Bonaccorso September 29, 2026 https://www.debian.org/security/faq - ------------------------------------------------------------------------- Package : linux CVE ID : CVE-2024-52560 CVE-2024-58094 CVE-2024-58095 CVE-2025-21817 CVE-2025-22104 CVE-2025-22108 CVE-2025-22127 CVE-2025-38203 CVE-2025-38205 CVE-2025-38206 CVE-2025-38237 CVE-2025-38621 CVE-2025-39833 CVE-2025-39925 CVE-2025-40064 CVE-2025-40102 CVE-2025-40139 CVE-2025-40168 CVE-2026-23137 CVE-2026-43198 CVE-2026-43344 CVE-2026-45963 CVE-2026-52944 CVE-2026-53010 CVE-2026-53089 CVE-2026-53102 CVE-2026-53113 CVE-2026-53250 CVE-2026-53313 CVE-2026-64058 CVE-2026-64070 CVE-2026-64082 CVE-2026-64210 CVE-2026-68286 CVE-2026-68287 CVE-2026-68288 CVE-2026-68289 CVE-2026-68303 CVE-2026-68337 CVE-2026-72334 CVE-2026-72402 CVE-2026-72413 CVE-2026-72438 CVE-2026-72485 CVE-2026-72496 CVE-2026-74258 CVE-2026-74268 CVE-2026-74289 CVE-2026-74291 CVE-2026-74294 CVE-2026-74334 CVE-2026-74496 CVE-2026-74521 CVE-2026-74735 CVE-2026-74753 CVE-2026-80521 CVE-2026-80671 CVE-2026-80755 CVE-2026-80762 CVE-2026-80766 CVE-2026-80768 CVE-2026-80774 CVE-2026-80780 CVE-2026-80783 CVE-2026-80796 CVE-2026-80806 CVE-2026-80807 CVE-2026-80824 CVE-2026-80825 CVE-2026-80826 CVE-2026-80827 CVE-2026-80828 CVE-2026-80829 CVE-2026-80830 CVE-2026-80831 CVE-2026-80832 CVE-2026-80833 CVE-2026-80834 CVE-2026-80835 CVE-2026-80836 CVE-2026-80837 CVE-2026-80838 CVE-2026-80839 CVE-2026-80840 CVE-2026-80841 CVE-2026-80842 CVE-2026-80843 CVE-2026-80844 CVE-2026-80845 CVE-2026-80846 CVE-2026-80847 CVE-2026-80848 CVE-2026-80849 CVE-2026-80850 CVE-2026-80851 CVE-2026-80852 CVE-2026-80854 CVE-2026-80855 CVE-2026-80856 CVE-2026-80860 CVE-2026-80861 CVE-2026-80862 CVE-2026-80863 CVE-2026-80864 CVE-2026-80878 CVE-2026-80914 CVE-2026-80921 CVE-2026-80922 CVE-2026-80923 CVE-2026-80925 CVE-2026-80926 CVE-2026-80928 CVE-2026-80930 CVE-2026-80931 CVE-2026-80932 CVE-2026-80933 CVE-2026-80938 CVE-2026-80940 CVE-2026-80941 CVE-2026-80942 CVE-2026-80943 CVE-2026-80944 CVE-2026-80945 CVE-2026-80947 CVE-2026-80949 CVE-2026-80951 CVE-2026-80952 CVE-2026-80963 CVE-2026-80964 CVE-2026-80965 CVE-2026-80966 CVE-2026-80967 CVE-2026-80968 CVE-2026-80969 CVE-2026-80971 CVE-2026-80972 CVE-2026-80973 CVE-2026-80974 CVE-2026-80976 CVE-2026-80977 CVE-2026-80978 CVE-2026-80979 CVE-2026-80982 CVE-2026-80983 CVE-2026-80984 CVE-2026-80987 CVE-2026-80988 CVE-2026-80989 CVE-2026-80990 CVE-2026-80991 CVE-2026-80992 CVE-2026-80994 CVE-2026-80996 CVE-2026-80997 CVE-2026-80999 CVE-2026-81000 CVE-2026-81001 CVE-2026-81002 CVE-2026-81003 CVE-2026-81005 CVE-2026-81007 CVE-2026-81008 CVE-2026-81011 CVE-2026-81012 CVE-2026-81013 CVE-2026-81014 CVE-2026-81017 CVE-2026-89438 CVE-2026-89439 CVE-2026-89440 CVE-2026-89442 CVE-2026-89443 CVE-2026-89444 CVE-2026-89448 CVE-2026-89451 CVE-2026-89453 CVE-2026-89454 CVE-2026-89455 CVE-2026-89456 CVE-2026-89457 CVE-2026-89458 CVE-2026-89460 CVE-2026-89461 CVE-2026-89462 CVE-2026-89463 CVE-2026-89464 CVE-2026-89465 CVE-2026-89466 CVE-2026-89468 CVE-2026-89469 CVE-2026-89470 CVE-2026-89471 CVE-2026-89472 CVE-2026-89473 CVE-2026-89474 CVE-2026-89475 CVE-2026-89476 CVE-2026-89477 CVE-2026-89478 CVE-2026-89479 CVE-2026-89480 CVE-2026-89481 CVE-2026-89482 CVE-2026-89483 CVE-2026-89484 CVE-2026-89485 CVE-2026-89487 CVE-2026-89488 CVE-2026-89489 CVE-2026-89490 CVE-2026-89491 CVE-2026-89492 CVE-2026-89493 CVE-2026-89494 CVE-2026-89495 CVE-2026-89496 CVE-2026-89497 CVE-2026-89498 CVE-2026-89501 CVE-2026-89502 CVE-2026-89504 CVE-2026-89508 CVE-2026-89510 CVE-2026-89511 CVE-2026-89512 CVE-2026-89515 CVE-2026-89524 CVE-2026-89525 CVE-2026-89526 CVE-2026-89530 CVE-2026-89531 CVE-2026-89532 CVE-2026-89533 CVE-2026-89535 CVE-2026-89536 CVE-2026-89538 CVE-2026-89539 CVE-2026-89540 CVE-2026-89541 CVE-2026-89542 CVE-2026-89543 CVE-2026-89544 CVE-2026-89545 CVE-2026-89547 CVE-2026-89548 CVE-2026-89549 CVE-2026-89550 CVE-2026-89551 CVE-2026-89552 CVE-2026-89553 CVE-2026-89554 CVE-2026-89555 CVE-2026-89557 CVE-2026-89558 CVE-2026-89559 CVE-2026-89560 CVE-2026-89561 CVE-2026-89562 CVE-2026-89563 CVE-2026-89564 CVE-2026-89565 CVE-2026-89566 CVE-2026-89567 CVE-2026-89569 CVE-2026-89572 CVE-2026-89573 CVE-2026-89574 CVE-2026-89575 CVE-2026-89576 CVE-2026-89579 CVE-2026-89580 CVE-2026-89581 CVE-2026-89582 CVE-2026-89583 CVE-2026-89585 CVE-2026-89586 CVE-2026-89587 CVE-2026-89588 CVE-2026-89589 CVE-2026-89593 CVE-2026-89594 CVE-2026-89595 CVE-2026-89596 CVE-2026-89597 CVE-2026-89598 CVE-2026-89599 CVE-2026-89602 CVE-2026-89603 CVE-2026-89604 CVE-2026-89605 CVE-2026-89606 CVE-2026-89607 CVE-2026-89608 CVE-2026-89609 CVE-2026-89615 CVE-2026-89616 CVE-2026-89617 CVE-2026-89618 CVE-2026-89621 CVE-2026-89622 CVE-2026-89624 CVE-2026-89625 CVE-2026-89626 CVE-2026-89627 CVE-2026-89628 CVE-2026-89634 CVE-2026-89636 CVE-2026-89640 CVE-2026-89643 CVE-2026-89644 CVE-2026-89645 CVE-2026-89647 CVE-2026-89649 CVE-2026-89650 CVE-2026-89651 CVE-2026-89652 CVE-2026-89653 CVE-2026-89655 CVE-2026-89656 CVE-2026-89657 CVE-2026-89658 CVE-2026-89659 CVE-2026-89660 CVE-2026-89662 CVE-2026-89663 CVE-2026-89665 CVE-2026-89666 CVE-2026-89667 CVE-2026-89669 CVE-2026-89671 CVE-2026-89672 CVE-2026-89674 CVE-2026-89676 CVE-2026-89680 CVE-2026-89683 CVE-2026-89684 CVE-2026-89685 CVE-2026-89686 CVE-2026-89688 CVE-2026-89690 CVE-2026-89691 CVE-2026-89693 CVE-2026-89694 CVE-2026-89696 CVE-2026-89697 CVE-2026-89698 CVE-2026-89699 CVE-2026-89700 CVE-2026-89702 CVE-2026-89703 CVE-2026-89704 CVE-2026-89706 CVE-2026-89707 CVE-2026-89708 CVE-2026-89710 CVE-2026-89711 CVE-2026-89712 CVE-2026-89713 CVE-2026-89717 CVE-2026-89718 CVE-2026-89719 CVE-2026-89720 CVE-2026-89723 CVE-2026-89724 CVE-2026-89725 CVE-2026-89726 CVE-2026-89729 CVE-2026-89730 CVE-2026-89731 CVE-2026-89732 CVE-2026-89733 CVE-2026-89735 CVE-2026-89736 CVE-2026-89738 CVE-2026-89740 CVE-2026-89741 CVE-2026-89742 CVE-2026-89743 CVE-2026-89744 CVE-2026-89746 CVE-2026-89747 CVE-2026-89749 CVE-2026-89750 CVE-2026-89751 CVE-2026-89752 CVE-2026-89753 CVE-2026-89755 CVE-2026-89756 CVE-2026-89759 CVE-2026-89761 CVE-2026-89762 CVE-2026-89763 CVE-2026-89765 CVE-2026-89768 CVE-2026-89771 CVE-2026-89776 CVE-2026-89777 CVE-2026-89778 CVE-2026-89779 CVE-2026-89780 CVE-2026-89781 CVE-2026-89782 CVE-2026-89783 CVE-2026-89784 CVE-2026-89785 CVE-2026-89786 CVE-2026-89787 CVE-2026-89789 CVE-2026-89792 CVE-2026-89793 CVE-2026-89794 CVE-2026-89796 CVE-2026-89798 CVE-2026-89799 CVE-2026-89800 CVE-2026-89801 CVE-2026-89802 CVE-2026-89803 CVE-2026-89807 CVE-2026-89816 CVE-2026-89817 CVE-2026-89818 CVE-2026-89819 CVE-2026-89821 CVE-2026-89822 CVE-2026-89823 CVE-2026-89824 CVE-2026-89825 CVE-2026-89830 CVE-2026-89834 CVE-2026-89835 CVE-2026-89839 CVE-2026-89842 CVE-2026-89843 CVE-2026-89844 CVE-2026-89845 CVE-2026-89846 CVE-2026-89847 CVE-2026-89848 CVE-2026-89849 CVE-2026-89850 CVE-2026-89851 CVE-2026-89852 CVE-2026-89853 CVE-2026-89854 CVE-2026-89855 CVE-2026-89856 CVE-2026-89857 CVE-2026-89858 CVE-2026-89860 CVE-2026-89861 CVE-2026-89863 CVE-2026-89864 CVE-2026-89865 CVE-2026-89870 CVE-2026-89871 CVE-2026-89872 CVE-2026-89874 CVE-2026-89876 CVE-2026-89877 CVE-2026-89878 CVE-2026-89879 CVE-2026-89880 CVE-2026-89881 CVE-2026-89883 CVE-2026-89884 CVE-2026-89885 CVE-2026-89886 CVE-2026-89887 CVE-2026-89888 CVE-2026-89890 CVE-2026-89891 CVE-2026-89892 CVE-2026-89893 CVE-2026-89894 CVE-2026-89895 CVE-2026-89896 CVE-2026-89897 CVE-2026-89898 CVE-2026-89899 CVE-2026-89900 CVE-2026-89901 CVE-2026-89902 CVE-2026-89903 CVE-2026-89904 CVE-2026-89908 CVE-2026-89909 CVE-2026-89922 CVE-2026-89923 CVE-2026-89924 CVE-2026-89925 CVE-2026-89926 CVE-2026-89927 CVE-2026-89929 CVE-2026-89930 CVE-2026-89931 CVE-2026-89932 CVE-2026-89933 CVE-2026-89934 CVE-2026-89936 CVE-2026-89937 CVE-2026-89938 CVE-2026-89939 CVE-2026-89940 CVE-2026-89941 CVE-2026-89942 CVE-2026-89943 CVE-2026-89944 CVE-2026-89945 CVE-2026-89946 CVE-2026-89947 CVE-2026-89948 CVE-2026-89949 CVE-2026-89950 CVE-2026-89951 CVE-2026-89952 CVE-2026-89953 CVE-2026-89954 CVE-2026-89955 CVE-2026-89957 CVE-2026-89958 CVE-2026-89959 CVE-2026-89960 CVE-2026-89961 CVE-2026-89962 CVE-2026-89963 CVE-2026-89964 CVE-2026-89965 CVE-2026-89968 CVE-2026-89969 CVE-2026-89970 CVE-2026-89973 CVE-2026-89974 CVE-2026-89975 CVE-2026-89979 CVE-2026-89980 CVE-2026-89982 CVE-2026-89983 CVE-2026-89984 CVE-2026-89986 CVE-2026-89988 CVE-2026-89989 CVE-2026-89990 CVE-2026-89992 CVE-2026-89993 CVE-2026-89994 CVE-2026-89995 CVE-2026-89997 CVE-2026-89998 CVE-2026-89999 CVE-2026-90000 CVE-2026-90001 CVE-2026-90003 CVE-2026-90007 CVE-2026-90011 CVE-2026-90012 CVE-2026-90015 CVE-2026-90017 CVE-2026-90018 CVE-2026-90019 CVE-2026-90020 CVE-2026-90021 CVE-2026-90022 CVE-2026-90024 CVE-2026-90025 CVE-2026-90026 CVE-2026-90027 CVE-2026-90031 CVE-2026-90032 CVE-2026-90033 CVE-2026-90034 CVE-2026-90035 CVE-2026-90036 CVE-2026-90037 CVE-2026-90039 CVE-2026-90041 CVE-2026-90042 CVE-2026-90044 CVE-2026-90045 CVE-2026-90048 CVE-2026-90049 CVE-2026-90053 CVE-2026-90054 CVE-2026-90055 CVE-2026-90056 CVE-2026-90057 CVE-2026-90058 CVE-2026-90060 CVE-2026-90062 CVE-2026-90063 CVE-2026-90065 CVE-2026-90066 CVE-2026-90067 CVE-2026-90068 CVE-2026-90070 CVE-2026-90071 CVE-2026-90072 CVE-2026-90073 CVE-2026-90074 CVE-2026-90075 CVE-2026-90076 CVE-2026-90078 CVE-2026-90081 CVE-2026-90085 CVE-2026-90088 CVE-2026-90090 CVE-2026-90091 CVE-2026-90092 CVE-2026-90101 CVE-2026-90102 CVE-2026-90103 CVE-2026-90107 CVE-2026-90108 CVE-2026-90109 CVE-2026-90110 CVE-2026-90112 CVE-2026-90114 CVE-2026-90115 CVE-2026-90119 CVE-2026-90122 CVE-2026-90124 CVE-2026-90125 CVE-2026-90126 CVE-2026-90128 CVE-2026-90130 CVE-2026-90135 CVE-2026-90137 CVE-2026-90138 CVE-2026-90139 CVE-2026-90140 CVE-2026-90141 CVE-2026-90143 CVE-2026-90147 CVE-2026-90148 CVE-2026-90150 CVE-2026-90151 CVE-2026-90152 CVE-2026-90153 CVE-2026-90157 CVE-2026-90158 CVE-2026-90159 CVE-2026-90160 CVE-2026-90165 CVE-2026-90166 CVE-2026-90169 CVE-2026-90170 CVE-2026-90175 CVE-2026-90176 CVE-2026-90178 CVE-2026-90180 CVE-2026-90184 CVE-2026-90185 CVE-2026-90186 CVE-2026-90187 CVE-2026-90188 CVE-2026-90189 CVE-2026-90190 CVE-2026-90192 CVE-2026-90193 CVE-2026-90194 CVE-2026-90195 CVE-2026-90196 CVE-2026-90198 CVE-2026-90199 CVE-2026-90200 CVE-2026-90201 CVE-2026-90202 CVE-2026-90203 CVE-2026-90207 CVE-2026-90209 CVE-2026-90213 CVE-2026-90214 CVE-2026-90215 CVE-2026-90216 CVE-2026-90218 CVE-2026-90219 CVE-2026-90220 CVE-2026-90221 CVE-2026-90222 CVE-2026-90223 CVE-2026-90224 CVE-2026-90225 CVE-2026-90226 CVE-2026-90227 CVE-2026-90228 CVE-2026-90229 CVE-2026-90230 CVE-2026-90235 CVE-2026-90241 CVE-2026-90243 CVE-2026-90245 CVE-2026-90248 CVE-2026-90249 CVE-2026-90250 CVE-2026-90251 CVE-2026-90253 CVE-2026-90254 CVE-2026-90255 CVE-2026-90257 CVE-2026-90262 CVE-2026-90274 CVE-2026-90275 CVE-2026-90279 CVE-2026-90280 CVE-2026-90281 CVE-2026-90282 CVE-2026-90283 CVE-2026-90284 CVE-2026-90285 CVE-2026-90286 CVE-2026-90287 CVE-2026-90290 CVE-2026-90291 CVE-2026-90292 CVE-2026-90293 CVE-2026-90294 CVE-2026-90295 CVE-2026-90296 CVE-2026-90297 CVE-2026-90298 CVE-2026-90302 CVE-2026-90303 CVE-2026-90307 CVE-2026-90308 CVE-2026-90309 CVE-2026-90313 CVE-2026-90314 CVE-2026-90316 CVE-2026-90318 CVE-2026-90319 CVE-2026-90322 CVE-2026-90325 CVE-2026-90327 CVE-2026-90329 CVE-2026-90334 CVE-2026-90341 CVE-2026-90344 CVE-2026-90348 CVE-2026-90352 CVE-2026-90353 CVE-2026-90354 CVE-2026-90357 CVE-2026-90358 CVE-2026-90360 CVE-2026-90361 CVE-2026-90362 CVE-2026-90364 CVE-2026-90366 CVE-2026-90368 CVE-2026-90370 CVE-2026-90372 CVE-2026-90373 CVE-2026-90374 CVE-2026-90375 CVE-2026-90378 CVE-2026-90380 CVE-2026-90382 CVE-2026-90383 CVE-2026-90385 CVE-2026-90386 CVE-2026-90387 CVE-2026-90388 CVE-2026-90389 CVE-2026-90390 CVE-2026-90391 CVE-2026-90392 CVE-2026-90393 CVE-2026-90394 CVE-2026-90395 CVE-2026-90397 CVE-2026-90398 CVE-2026-90399 CVE-2026-90400 CVE-2026-90402 CVE-2026-90403 CVE-2026-90404 CVE-2026-90407 CVE-2026-90410 CVE-2026-90411 CVE-2026-90413 CVE-2026-90414 CVE-2026-90415 CVE-2026-90416 CVE-2026-90418 CVE-2026-90419 CVE-2026-90420 CVE-2026-90426 CVE-2026-90428 CVE-2026-90430 CVE-2026-90431 CVE-2026-90433 CVE-2026-90434 CVE-2026-90435 CVE-2026-92476 CVE-2026-92477 CVE-2026-92481 CVE-2026-92484 CVE-2026-92488 CVE-2026-92489 CVE-2026-92490 CVE-2026-92491 CVE-2026-92494 CVE-2026-92495 CVE-2026-92496 CVE-2026-92497 CVE-2026-92498 CVE-2026-92501 CVE-2026-92502 CVE-2026-92504 CVE-2026-92506 CVE-2026-92507 CVE-2026-92508 CVE-2026-92509 CVE-2026-92510 CVE-2026-92511 CVE-2026-92512 CVE-2026-92514 CVE-2026-92515 CVE-2026-92519 CVE-2026-92521 CVE-2026-92522 CVE-2026-92523 CVE-2026-92524 CVE-2026-92525 CVE-2026-93037 CVE-2026-93039 CVE-2026-93040 CVE-2026-93041 CVE-2026-93042 CVE-2026-93045 CVE-2026-93046 CVE-2026-93048 CVE-2026-93049 CVE-2026-93050 CVE-2026-93051 CVE-2026-93052 CVE-2026-93053 CVE-2026-93054 CVE-2026-93055 CVE-2026-93056 CVE-2026-93061 CVE-2026-93062 CVE-2026-93063 CVE-2026-93064 CVE-2026-93065 CVE-2026-93067 CVE-2026-93070 CVE-2026-93071 CVE-2026-93072 CVE-2026-93073 CVE-2026-93082 CVE-2026-93083 CVE-2026-93084 CVE-2026-93085 CVE-2026-93086 CVE-2026-93089 CVE-2026-93090 CVE-2026-93091 CVE-2026-93092 CVE-2026-93093 CVE-2026-93095 CVE-2026-93097 CVE-2026-93098 CVE-2026-93101 CVE-2026-93102 CVE-2026-93103 CVE-2026-93107 CVE-2026-93108 CVE-2026-93109 CVE-2026-93110 CVE-2026-93113 CVE-2026-93114 CVE-2026-93115 CVE-2026-93117 CVE-2026-93118 CVE-2026-93119 CVE-2026-93120 CVE-2026-93121 CVE-2026-93123 CVE-2026-93126 CVE-2026-93128 CVE-2026-93130 CVE-2026-93131 CVE-2026-93132 CVE-2026-93133 CVE-2026-93134 CVE-2026-93136 CVE-2026-93137 CVE-2026-93138 CVE-2026-93140 CVE-2026-93141 CVE-2026-93142 CVE-2026-93145 CVE-2026-93149 CVE-2026-93150 CVE-2026-93151 CVE-2026-93152 CVE-2026-93155 CVE-2026-93156 CVE-2026-93158 CVE-2026-93159 CVE-2026-93160 CVE-2026-93161 CVE-2026-93162 CVE-2026-93163 CVE-2026-93165 CVE-2026-93167 CVE-2026-93170 CVE-2026-93172 CVE-2026-93173 CVE-2026-93174 CVE-2026-93177 CVE-2026-93178 CVE-2026-93182 CVE-2026-93183 CVE-2026-93184 CVE-2026-93185 CVE-2026-93186 CVE-2026-93188 CVE-2026-93189 CVE-2026-93190 CVE-2026-93191 CVE-2026-93192 CVE-2026-93203 CVE-2026-93204 CVE-2026-93205 CVE-2026-93206 CVE-2026-93207 CVE-2026-93208 CVE-2026-93209 CVE-2026-93210 CVE-2026-93211 CVE-2026-93212 CVE-2026-93213 CVE-2026-93214 CVE-2026-93215 CVE-2026-93219 CVE-2026-93222 CVE-2026-93223 CVE-2026-93224 CVE-2026-93226 CVE-2026-93228 CVE-2026-93229 CVE-2026-93234 CVE-2026-93235 CVE-2026-93236 CVE-2026-93238 CVE-2026-93239 CVE-2026-93240 CVE-2026-93242 CVE-2026-93245 CVE-2026-93247 CVE-2026-93250 CVE-2026-93252 CVE-2026-93256 CVE-2026-93259 CVE-2026-93261 CVE-2026-93262 CVE-2026-93264 CVE-2026-93268 CVE-2026-93269 CVE-2026-93271 CVE-2026-93273 CVE-2026-93274 CVE-2026-93275 CVE-2026-93278 CVE-2026-93279 CVE-2026-93280 CVE-2026-93281 CVE-2026-93283 CVE-2026-93286 CVE-2026-93287 CVE-2026-93288 CVE-2026-93781 CVE-2026-93782 CVE-2026-93783 CVE-2026-93784 CVE-2026-93785 CVE-2026-93786 CVE-2026-93787 CVE-2026-93788 CVE-2026-93789 CVE-2026-93790 CVE-2026-93791 CVE-2026-93792 CVE-2026-93793 CVE-2026-93794 CVE-2026-93795 CVE-2026-93796 CVE-2026-93797 CVE-2026-93798 CVE-2026-93799 CVE-2026-93800 CVE-2026-93801 CVE-2026-93802 CVE-2026-93803 CVE-2026-93804 CVE-2026-93805 CVE-2026-93806 CVE-2026-93807 CVE-2026-93808 CVE-2026-93810 CVE-2026-93811 CVE-2026-93812 CVE-2026-93813 CVE-2026-93814 CVE-2026-93815 CVE-2026-93816 CVE-2026-93817 CVE-2026-93818 CVE-2026-93819 CVE-2026-93820 CVE-2026-93821 CVE-2026-93822 CVE-2026-93823 CVE-2026-93824 CVE-2026-93825 CVE-2026-93826 CVE-2026-93827 CVE-2026-93828 CVE-2026-93829 CVE-2026-93830 CVE-2026-97407 CVE-2026-97408 CVE-2026-97409 CVE-2026-97410 CVE-2026-97411 CVE-2026-97412 CVE-2026-97413 CVE-2026-97414 CVE-2026-97415 CVE-2026-97416 CVE-2026-97417 CVE-2026-97418 CVE-2026-97419 CVE-2026-97420 CVE-2026-97421 CVE-2026-97425 CVE-2026-97427 CVE-2026-97428 CVE-2026-97429 CVE-2026-97430 CVE-2026-97434 CVE-2026-97435 CVE-2026-97436 CVE-2026-97437 CVE-2026-97438 CVE-2026-97439 CVE-2026-97440 CVE-2026-97441 CVE-2026-97442 CVE-2026-97443 CVE-2026-97444 CVE-2026-97445 CVE-2026-97446 CVE-2026-97448 CVE-2026-97449 CVE-2026-97450 CVE-2026-97451 CVE-2026-97452 CVE-2026-97453 CVE-2026-97454 CVE-2026-97455 CVE-2026-97456 CVE-2026-97472 CVE-2026-97473 CVE-2026-97475 CVE-2026-97476 CVE-2026-97481 CVE-2026-97482 CVE-2026-97483 CVE-2026-97484 CVE-2026-97485 CVE-2026-97486 CVE-2026-97487 CVE-2026-97488 CVE-2026-97489 CVE-2026-97490 CVE-2026-97491 CVE-2026-97492 CVE-2026-97494 CVE-2026-97495 CVE-2026-97496 CVE-2026-97497 CVE-2026-97500 CVE-2026-97502 CVE-2026-97504 CVE-2026-97505 CVE-2026-97506 CVE-2026-97507 CVE-2026-97508 CVE-2026-97509 CVE-2026-97510 CVE-2026-97512 CVE-2026-97514 CVE-2026-97516 CVE-2026-97517 CVE-2026-97518 CVE-2026-97520 CVE-2026-97521 CVE-2026-97522 CVE-2026-97523 CVE-2026-97524 CVE-2026-97539 CVE-2026-97540 CVE-2026-97541 CVE-2026-97542 CVE-2026-97543 CVE-2026-97544 CVE-2026-97545 CVE-2026-97546 CVE-2026-97547 CVE-2026-97551 CVE-2026-97552 CVE-2026-97555 CVE-2026-97556 CVE-2026-97557 CVE-2026-97560 CVE-2026-97562 CVE-2026-97564 CVE-2026-97568 CVE-2026-97572 CVE-2026-97573 CVE-2026-97575 CVE-2026-97576 CVE-2026-97577 CVE-2026-97578 CVE-2026-97579 CVE-2026-97581 CVE-2026-97582 CVE-2026-97583 CVE-2026-97584 CVE-2026-97587 CVE-2026-97592 CVE-2026-97595 CVE-2026-97596 CVE-2026-97598 CVE-2026-97599 CVE-2026-97600 CVE-2026-97601 CVE-2026-97602 CVE-2026-97604 CVE-2026-97605 CVE-2026-97606 CVE-2026-97607 CVE-2026-97608 CVE-2026-97611 CVE-2026-97612 CVE-2026-97613 CVE-2026-97616 CVE-2026-97617 CVE-2026-97899 CVE-2026-97900 CVE-2026-97902 CVE-2026-97904 CVE-2026-97905 CVE-2026-97907 CVE-2026-97908 CVE-2026-97909 CVE-2026-97910 CVE-2026-97915 CVE-2026-97916 CVE-2026-97917 CVE-2026-97920 CVE-2026-97921 CVE-2026-97922 CVE-2026-97923 CVE-2026-97924 CVE-2026-97925 CVE-2026-97926 CVE-2026-97927 CVE-2026-97929 CVE-2026-97930 CVE-2026-97931 CVE-2026-97936 CVE-2026-97940 CVE-2026-97945 CVE-2026-97948 CVE-2026-97951 CVE-2026-97952 CVE-2026-97953 CVE-2026-97954 CVE-2026-97957 CVE-2026-97958 CVE-2026-97959 CVE-2026-97961 CVE-2026-97963 CVE-2026-97964 CVE-2026-97965 CVE-2026-97966 CVE-2026-97967 CVE-2026-97968 CVE-2026-97969 CVE-2026-97970 CVE-2026-97973 CVE-2026-97976 CVE-2026-97977 CVE-2026-97978 CVE-2026-97979 CVE-2026-97981 CVE-2026-97982 CVE-2026-97984 CVE-2026-97985 CVE-2026-97986 CVE-2026-97987 CVE-2026-97990 CVE-2026-97991 CVE-2026-97992 CVE-2026-97993 CVE-2026-97994 CVE-2026-97995 CVE-2026-97996 CVE-2026-97998 CVE-2026-98001 CVE-2026-98006 CVE-2026-98007 CVE-2026-98008 CVE-2026-98009 CVE-2026-98010 CVE-2026-98011 CVE-2026-98012 CVE-2026-98013 CVE-2026-98014 CVE-2026-98015 CVE-2026-98016 CVE-2026-98017 CVE-2026-98018 CVE-2026-98020 CVE-2026-98021 CVE-2026-98022 CVE-2026-98023 CVE-2026-98024 CVE-2026-98025 CVE-2026-98026 CVE-2026-98027 CVE-2026-98028 CVE-2026-98029 CVE-2026-98030 CVE-2026-98031 CVE-2026-98037 CVE-2026-98039 CVE-2026-98041 CVE-2026-98045 CVE-2026-98046 CVE-2026-98051 CVE-2026-98052 CVE-2026-98054 CVE-2026-98055 CVE-2026-98056 CVE-2026-98057 CVE-2026-98059 CVE-2026-98063 CVE-2026-98064 CVE-2026-98066 CVE-2026-98068 CVE-2026-98069 CVE-2026-98070 CVE-2026-98071 CVE-2026-98072 CVE-2026-98074 CVE-2026-98075 CVE-2026-98076 CVE-2026-98077 CVE-2026-98078 CVE-2026-98080 CVE-2026-98081 CVE-2026-98082 CVE-2026-98083 CVE-2026-98086 CVE-2026-98088 CVE-2026-98089 CVE-2026-98090 CVE-2026-98091 CVE-2026-98092 CVE-2026-98094 CVE-2026-98095 CVE-2026-98096 CVE-2026-98097 CVE-2026-98098 CVE-2026-98102 CVE-2026-98103 CVE-2026-98104 CVE-2026-98105 CVE-2026-98107 CVE-2026-98108 CVE-2026-98109 CVE-2026-98110 CVE-2026-98111 CVE-2026-98113 CVE-2026-98114 CVE-2026-98116 CVE-2026-98121 CVE-2026-98122 CVE-2026-98123 CVE-2026-98126 CVE-2026-98127 CVE-2026-98128 CVE-2026-98129 CVE-2026-98130 CVE-2026-98142 CVE-2026-98151 CVE-2026-98152 CVE-2026-98154 CVE-2026-98155 CVE-2026-98157 CVE-2026-98158 CVE-2026-98159 CVE-2026-98160 CVE-2026-100070 CVE-2026-100071 CVE-2026-100075 CVE-2026-100078 CVE-2026-100079 Debian Bug : 1108860 Several vulnerabilities have been discovered in the Linux kernel that may lead to a privilege escalation, denial of service or information leaks. For the stable distribution (trixie), these problems have been fixed in version 6.12.111-1. We recommend that you upgrade your linux packages. For the detailed security status of linux please refer to its security tracker page at: https://security-tracker.debian.org/tracker/linux Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-announce@lists.debian.org -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmq7iIBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xND z0T8dg/+JqQiolcEcegl7lN/YqP2fvTJc4FYTlRFZQdWU5oYMDbkQh/SHFoxXrJf gn7NWBWYGt1Snkf/D36p4jDMqxVm3Qom6UPvAuT7TQA80YTNm6Tynb+IK7W1ko8u JjEjN8KZD92K9KzItIbZj6qYa9JX3pPkXAwzuzcdOwM6vYVpG5mZmZB96sc8QCNd zEQGoyoa0KT+oedL1x3t0KfTawT0kH/HM/eVc8kv4zO+IpCzUVEtRa/JxSM67/l2 l1qxRdRWeuK3AF0qxP/nqdWxlqNCYwh0SEdQfJm5P8kwZc9d+UO+U4SMuvComWLP 9uoQYcBbPEQRh8CZuhxFNGKJ3uf0OZ8jJR5YFJyYJpIximc+e3EgAZ3b2DfVu9hN vnvW8hmqsE8ssaxGCSqSSKLV9TgaAHMFPMQ2/WItx1dQVqB6pt0oxnTQNbjPF4V4 tuqHu40hp1Wmtuyr5p+X9OoKEjAIG4gagLup4Ijj7iSez81ihjAOUBjeYQ68MlqQ 36g6IkQ7fZkbbZyViyPuhUPnjJcK0ywE0Xy42fJQvDime75wzBru+HFPmhqHtqET j0ddKW4vX1JXqQxyhty0qWVO0z1lo95XLjkluDEUPjTXr6NPu7oSNZeO9quOpO1K Sy4nKIrpztiu4vpsh7XSzUGkXBKz7TKEplxuZfKnlG5ltlBuKk0= =ziCh -----END PGP SIGNATURE-----
Text extracted automatically; images, tables and formatting may be missing. Original: https://lwn.net/Articles/1097401/
Linux kernel: ibmvnic: Use kernel helpers for hex dumps In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Use kernel helpers for hex dumps Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible. Therefore, create a new ibmvnic function that loops over a buffer and calls hex_dump_to_buffer instead. This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 Allocated by task 17681: ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) ================================================================= ibmvnic 30000003 env3: 000000000033766e NVD description · AI analysis pending |
| 7.1 group max |
| <1% |
|
| — |
CVE-2025-38206+2 related CVEs | Linux kernel: exfat: fix double free in delayed_free In the Linux kernel, the following vulnerability has been resolved: exfat: fix double free in delayed_free The double free could happen in the following path. exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() vol_util as NULL after freeing it. NVD description · AI analysis pending | 7.8 group max | <1% |
| — |
| CVE-2025-38237 | Linux kernel: media: platform: exynos4-is: Add hardware sync wait to fimc_is_hw_change_mode() In the Linux kernel, the following vulnerability has been resolved: media: platform: exynos4-is: Add hardware sync wait to fimc_is_hw_change_mode() In fimc_is_hw_change_mode(), the function changes camera modes without waiting for hardware completion, risking corrupted data or system hangs if subsequent operations proceed before the hardware is ready. Add fimc_is_hw_wait_intmsr0_intmsd0() after mode configuration, ensuring hardware state synchronization and stable interrupt handling. NVD description · AI analysis pending | 5.5 | <1% |
| — |
| CVE-2025-38621 | Linux kernel: md: make rdev_addable usable for rcu mode Our testcase trigger panic In the Linux kernel, the following vulnerability has been resolved: md: make rdev_addable usable for rcu mode Our testcase trigger panic: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0 md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive. NVD description · AI analysis pending | 5.5 | <1% |
| — |
| CVE-2025-39833 | Linux kernel: mISDN: hfcpci In the Linux kernel, the following vulnerability has been resolved: mISDN: hfcpci: Fix warning when deleting uninitialized timer With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads to the following splat: [ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0 [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDN_core [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary) [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0 [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286 [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0 [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39 [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001 [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8 [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000 [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0 [ 250.236117] Call Trace: [ 250.236599] [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130 [ 250.237920] debug_object_assert_init+0x1f6/0x310 [ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10 [ 250.239658] ? __lock_acquire+0xdea/0x1c70 [ 250.240369] __try_to_del_timer_sync+0x69/0x140 [ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10 [ 250.242058] ? __timer_delete_sync+0xc6/0x120 [ 250.242842] ? lock_acquire+0x30/0x80 [ 250.243474] ? __timer_delete_sync+0xc6/0x120 [ 250.244262] __timer_delete_sync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] __do_sys_delete_module+0x348/0x510 [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10 [ 250.247338] do_syscall_64+0xc1/0x360 [ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by initializing hfc_tl timer with DEFINE_TIMER macro. Also, use mod_timer instead of manual timeout update. NVD description · AI analysis pending | 5.5 | <1% |
| — |
| CVE-2025-39925 | Linux kernel: can: j1939: implement NETDEV_UNREGISTER notification handler In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on "struct j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label] NVD description · AI analysis pending | 5.5 | <1% |
| — |
| CVE-2025-40064 | Linux kernel: smc In the Linux kernel, the following vulnerability has been resolved: smc: Fix use-after-free in __pnet_find_base_ndev(). syzbot reported use-after-free of net_device in __pnet_find_base_ndev(), which was called during connect(). [0] smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passes down to pnet_find_base_ndev(), where RTNL is held. Then, UAF happened at __pnet_find_base_ndev() when the dev is first used. This means dev had already been freed before acquiring RTNL in pnet_find_base_ndev(). While dev is going away, dst->dev could be swapped with blackhole_netdev, and the dev's refcnt by dst will be released. We must hold dev's refcnt before calling smc_pnet_find_ism_resource(). Also, smc_pnet_find_roce_resource() has the same problem. Let's use __sk_dst_get() and dst_dev_rcu() in the two functions. [0]: BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609 CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f47cbf8eba9 Code: 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9 RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000 raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node ---truncated--- NVD description · AI analysis pending | 7.8 | <1% |
| — |
| CVE-2025-40102 | Linux kernel: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously… In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. 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: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state. NVD description · AI analysis pending | — | <1% |
| — |
CVE-2025-40168+1 related CVE | Linux kernel: smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match(). smc_clc_prfx_match() is called from… In the Linux kernel, the following vulnerability has been resolved: smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match(). smc_clc_prfx_match() is called from smc_listen_work() and not under RCU nor RTNL. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the returned value of smc_clc_prfx_match() is not used in the caller. NVD description · AI analysis pending | 8.1 group max | <1% |
| — |
| CVE-2026-23137 | Linux kernel: of: unittest In the Linux kernel, the following vulnerability has been resolved: of: unittest: Fix memory leak in unittest_data_add() In unittest_data_add(), if of_resolve_phandles() fails, the allocated unittest_data is not freed, leading to a memory leak. Fix this by using scope-based cleanup helper __free(kfree) for automatic resource cleanup. This ensures unittest_data is automatically freed when it goes out of scope in error paths. For the success path, use retain_and_null_ptr() to transfer ownership of the memory to the device tree and prevent double freeing. NVD description · AI analysis pending | 5.5 | <1% |
| — |
| CVE-2026-43198 | Linux kernel: tcp: fix potential race in tcp_v6_syn_recv_sock() Code in tcp_v6_syn_recv_sock() after the call to… In the Linux kernel, the following vulnerability has been resolved: tcp: fix potential race in tcp_v6_syn_recv_sock() Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context. NVD description · AI analysis pending | 9.8 | <1% |
| — |
| CVE-2026-43344 | Linux kernel: perf/x86/intel/uncore In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix die ID init and look up bugs In snbep_pci2phy_map_init(), in the nr_node_ids > 8 path, uncore_device_to_die() may return -1 when all CPUs associated with the UBOX device are offline. Remove the WARN_ON_ONCE(die_id == -1) check for two reasons: - The current code breaks out of the loop. This is incorrect because pci_get_device() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan. - Returning -EINVAL is incorrect, since marking offline buses with die_id == -1 is expected and should not be treated as an error. Separately, when NUMA is disabled on a NUMA-capable platform, pcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die() to return -1 for all PCI devices. As a result, spr_update_device_location(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree. Fix this by using uncore_pcibus_to_dieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbep_pci2phy_map_init() to be added in spr_uncore_pci_init(). Keep uncore_device_to_die() only for the nr_node_ids > 8 case, where NUMA is expected to be enabled. NVD description · AI analysis pending | 5.5 | <1% |
| — |
| CVE-2026-45963 | Linux kernel: ASoC: nau8821: Cancel delayed work on component remove Attempting to unload the driver while a jack detection… In the Linux kernel, the following vulnerability has been resolved: ASoC: nau8821: Cancel delayed work on component remove Attempting to unload the driver while a jack detection work is pending would likely crash the kernel when it is eventually scheduled for execution: [ 1984.896308] BUG: unable to handle page fault for address: ffffffffc10c2a20 [...] [ 1984.896388] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024 [ 1984.896396] Workqueue: events nau8821_jdet_work [snd_soc_nau8821] [ 1984.896414] RIP: 0010:__mutex_lock+0x9f/0x11d0 [...] [ 1984.896504] Call Trace: [ 1984.896511] [ 1984.896524] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896572] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896596] snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896622] nau8821_jdet_work+0xeb/0x1e0 [snd_soc_nau8821] [ 1984.896636] process_one_work+0x211/0x590 [ 1984.896649] ? srso_return_thunk+0x5/0x5f [ 1984.896670] worker_thread+0x1cd/0x3a0 Cancel unscheduled jdet_work or wait for its execution to finish before the component driver gets removed. NVD description · AI analysis pending | 5.5 | <1% |
| — |
CVE-2026-53010+4 related CVEs | Linux kernel: ksmbd: fix use-after-free in smb2_open during durable reconnect In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in smb2_open during durable reconnect In smb2_open, the call to ksmbd_put_durable_fd(fp) drops the reference to the durable file descriptor early during the durable reconnect process. If an error occurs subsequently (eg, ksmbd_iov_pin_rsp fails) or a scavenger accesses the file, it leads to a use-after-free when accessing fp properties (eg fp->create_time). Move the single put to the end of the function below err_out2 so fp stays valid until smb2_open returns. NVD description · AI analysis pending | 9.8 group max | <1% |
| — |
| CVE-2026-53250 | Linux kernel: xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata() In the Linux kernel, the following vulnerability has been resolved: xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata() The TX metadata area resides in the UMEM buffer which is memory-mapped and concurrently writable by userspace. In xsk_skb_metadata(), csum_start and csum_offset are read from shared memory for bounds validation, then read again for skb assignment. A malicious userspace application can race to overwrite these values between the two reads, bypassing the bounds check and causing out-of-bounds memory access during checksum computation in the transmit path. Fix this by reading csum_start and csum_offset into local variables once, then using the local copies for both validation and assignment. Note that other metadata fields (flags, launch_time) and the cached csum fields may be mutually inconsistent due to concurrent userspace writes, but this is benign: the only security-critical invariant is that each field's validated value is the same one used, which local caching guarantees. NVD description · AI analysis pending | 7.8 | <1% |
| — |
| CVE-2026-53313 | Linux kernel: drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(). Both functions check: if (!dc_dmub_srv || !dc_dmub_srv->dmub) and then call DC_LOG_ERROR() inside that block. DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash. Fix this by splitting the checks. First check if dc_dmub_srv is NULL and return immediately. Then check dc_dmub_srv->dmub and log the error only when dc_dmub_srv is valid. Fixes the below: ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961) ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166) NVD description · AI analysis pending | 5.5 | <1% |
| — |
| CVE-2026-64058 | Linux kernel: netfs In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_read_folio() to wait on writeback Fix netfs_read_folio() to wait for an ongoing writeback to complete so that it can trust the dirty flag and whatever is attached to folio->private (folio->private may get cleaned up by the collector before it clears the writeback flag). NVD description · AI analysis pending | 7.8 | <1% |
| — |