ALT-BU-2021-4589-2
Branch sisyphus update bulletin.
Package plasma5-workspace updated to version 5.23.4-alt5 for branch sisyphus in task 291929.
Closed bugs
"Показать строку поиска и запуска" отсутствует
Closed vulnerabilities
BDU:2022-00592
Уязвимость пакета управления рассылками электронных писем GNU Mailman, связанная с недостаточной проверкой источника HTTP-запроса, позволяющая нарушителю выполнять атаки с подделкой межсайтовых запросов
Modified: 2024-11-21
CVE-2021-42097
GNU Mailman before 2.1.35 may allow remote Privilege Escalation. A csrf_token value is not specific to a single user account. An attacker can obtain a value within the context of an unprivileged user account, and then use that value in a CSRF attack against an admin (e.g., for account takeover).
- http://www.openwall.com/lists/oss-security/2021/10/21/4
- https://bugs.launchpad.net/mailman/+bug/1947640
- https://mail.python.org/archives/list/mailman-announce%40python.org/thread/IKCO6JU755AP5G5TKMBJL6IEZQTTNPDQ/
- https://www.debian.org/security/2021/dsa-4991
- http://www.openwall.com/lists/oss-security/2021/10/21/4
- https://bugs.launchpad.net/mailman/+bug/1947640
- https://mail.python.org/archives/list/mailman-announce%40python.org/thread/IKCO6JU755AP5G5TKMBJL6IEZQTTNPDQ/
- https://www.debian.org/security/2021/dsa-4991
Modified: 2024-11-21
CVE-2021-44227
In GNU Mailman before 2.1.38, a list member or moderator can get a CSRF token and craft an admin request (using that token) to set a new admin password or make other changes.
Modified: 2021-12-07
GHSA-xq58-69h2-765m
Cross Site Request Forgery in mailman
Package xorg-server updated to version 1.20.13-alt5 for branch sisyphus in task 291952.
Closed vulnerabilities
Modified: 2024-09-16
BDU:2022-00346
Уязвимость функции SProcXFixesCreatePointerBarrier реализации сервера X Window System X.Org Server, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-09-16
BDU:2022-00347
Уязвимость функции SProcXFixesCreatePointerBarrier реализации сервера X Window System X.Org Server, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-09-16
BDU:2022-00348
Уязвимость функции SProcRenderCompositeGlyphs реализации сервера X Window System X.Org Server, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-09-24
BDU:2022-00349
Уязвимость функции SwapCreateRegister реализации сервера X Window System X.Org Server, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2021-4008
A flaw was found in xorg-x11-server in versions before 21.1.2 and before 1.20.14. An out-of-bounds access can occur in the SProcRenderCompositeGlyphs function. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
- https://lists.debian.org/debian-lts-announce/2021/12/msg00035.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NKLSZCY47QK4RCJFXITYFALCGPJAFXOK/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NXTRPFEQLFZ6NT2LPLZEID664RGC3OCC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PDHYZM6FII35JA7J275MFCJO6ADJUPQX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T57DCF726O5LLTST4NBL5PQ7DLPB46HT/
- https://lists.x.org/archives/xorg-announce/2021-December/003122.html
- https://lists.x.org/archives/xorg-announce/2021-December/003124.html
- https://security.gentoo.org/glsa/202305-30
- https://security.netapp.com/advisory/ntap-20220114-0004/
- https://www.debian.org/security/2021/dsa-5027
- https://www.zerodayinitiative.com/advisories/ZDI-21-1547/
- https://lists.debian.org/debian-lts-announce/2021/12/msg00035.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NKLSZCY47QK4RCJFXITYFALCGPJAFXOK/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NXTRPFEQLFZ6NT2LPLZEID664RGC3OCC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PDHYZM6FII35JA7J275MFCJO6ADJUPQX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T57DCF726O5LLTST4NBL5PQ7DLPB46HT/
- https://lists.x.org/archives/xorg-announce/2021-December/003122.html
- https://lists.x.org/archives/xorg-announce/2021-December/003124.html
- https://security.gentoo.org/glsa/202305-30
- https://security.netapp.com/advisory/ntap-20220114-0004/
- https://www.debian.org/security/2021/dsa-5027
- https://www.zerodayinitiative.com/advisories/ZDI-21-1547/
Modified: 2024-11-21
CVE-2021-4009
A flaw was found in xorg-x11-server in versions before 21.1.2 and before 1.20.14. An out-of-bounds access can occur in the SProcXFixesCreatePointerBarrier function. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
- https://lists.debian.org/debian-lts-announce/2021/12/msg00035.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NKLSZCY47QK4RCJFXITYFALCGPJAFXOK/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NXTRPFEQLFZ6NT2LPLZEID664RGC3OCC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PDHYZM6FII35JA7J275MFCJO6ADJUPQX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T57DCF726O5LLTST4NBL5PQ7DLPB46HT/
- https://lists.x.org/archives/xorg-announce/2021-December/003122.html
- https://lists.x.org/archives/xorg-announce/2021-December/003124.html
- https://security.gentoo.org/glsa/202305-30
- https://security.netapp.com/advisory/ntap-20220114-0004/
- https://www.debian.org/security/2021/dsa-5027
- https://www.zerodayinitiative.com/advisories/ZDI-21-1548/
- https://lists.debian.org/debian-lts-announce/2021/12/msg00035.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NKLSZCY47QK4RCJFXITYFALCGPJAFXOK/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NXTRPFEQLFZ6NT2LPLZEID664RGC3OCC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PDHYZM6FII35JA7J275MFCJO6ADJUPQX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T57DCF726O5LLTST4NBL5PQ7DLPB46HT/
- https://lists.x.org/archives/xorg-announce/2021-December/003122.html
- https://lists.x.org/archives/xorg-announce/2021-December/003124.html
- https://security.gentoo.org/glsa/202305-30
- https://security.netapp.com/advisory/ntap-20220114-0004/
- https://www.debian.org/security/2021/dsa-5027
- https://www.zerodayinitiative.com/advisories/ZDI-21-1548/
Modified: 2024-11-21
CVE-2021-4010
A flaw was found in xorg-x11-server in versions before 21.1.2 and before 1.20.14. An out-of-bounds access can occur in the SProcScreenSaverSuspend function. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NKLSZCY47QK4RCJFXITYFALCGPJAFXOK/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NXTRPFEQLFZ6NT2LPLZEID664RGC3OCC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PDHYZM6FII35JA7J275MFCJO6ADJUPQX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T57DCF726O5LLTST4NBL5PQ7DLPB46HT/
- https://lists.x.org/archives/xorg-announce/2021-December/003122.html
- https://lists.x.org/archives/xorg-announce/2021-December/003124.html
- https://security.gentoo.org/glsa/202305-30
- https://security.netapp.com/advisory/ntap-20220114-0004/
- https://www.debian.org/security/2021/dsa-5027
- https://www.zerodayinitiative.com/advisories/ZDI-21-1549/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NKLSZCY47QK4RCJFXITYFALCGPJAFXOK/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NXTRPFEQLFZ6NT2LPLZEID664RGC3OCC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PDHYZM6FII35JA7J275MFCJO6ADJUPQX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T57DCF726O5LLTST4NBL5PQ7DLPB46HT/
- https://lists.x.org/archives/xorg-announce/2021-December/003122.html
- https://lists.x.org/archives/xorg-announce/2021-December/003124.html
- https://security.gentoo.org/glsa/202305-30
- https://security.netapp.com/advisory/ntap-20220114-0004/
- https://www.debian.org/security/2021/dsa-5027
- https://www.zerodayinitiative.com/advisories/ZDI-21-1549/
Modified: 2024-11-21
CVE-2021-4011
A flaw was found in xorg-x11-server in versions before 21.1.2 and before 1.20.14. An out-of-bounds access can occur in the SwapCreateRegister function. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
- https://lists.debian.org/debian-lts-announce/2021/12/msg00035.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NKLSZCY47QK4RCJFXITYFALCGPJAFXOK/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NXTRPFEQLFZ6NT2LPLZEID664RGC3OCC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PDHYZM6FII35JA7J275MFCJO6ADJUPQX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T57DCF726O5LLTST4NBL5PQ7DLPB46HT/
- https://lists.x.org/archives/xorg-announce/2021-December/003122.html
- https://lists.x.org/archives/xorg-announce/2021-December/003124.html
- https://security.gentoo.org/glsa/202305-30
- https://security.netapp.com/advisory/ntap-20220114-0004/
- https://www.debian.org/security/2021/dsa-5027
- https://www.zerodayinitiative.com/advisories/ZDI-21-1550/
- https://lists.debian.org/debian-lts-announce/2021/12/msg00035.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NKLSZCY47QK4RCJFXITYFALCGPJAFXOK/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NXTRPFEQLFZ6NT2LPLZEID664RGC3OCC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PDHYZM6FII35JA7J275MFCJO6ADJUPQX/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T57DCF726O5LLTST4NBL5PQ7DLPB46HT/
- https://lists.x.org/archives/xorg-announce/2021-December/003122.html
- https://lists.x.org/archives/xorg-announce/2021-December/003124.html
- https://security.gentoo.org/glsa/202305-30
- https://security.netapp.com/advisory/ntap-20220114-0004/
- https://www.debian.org/security/2021/dsa-5027
- https://www.zerodayinitiative.com/advisories/ZDI-21-1550/
Closed vulnerabilities
Modified: 2024-04-03
BDU:2021-06051
Уязвимость компонента BFCache браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2026-04-27
BDU:2021-06100
Уязвимость расширений браузера Google Chrome, позволяющая нарушителю выполнить произвольный код
Modified: 2026-04-27
BDU:2021-06101
Уязвимость компонента UI браузера Google Chrome, позволяющая нарушителю выполнить произвольный код
Modified: 2026-04-27
BDU:2021-06102
Уязвимость веб-приложений браузера Google Chrome, позволяющая нарушителю выполнить произвольный код
Modified: 2024-04-03
BDU:2021-06117
Уязвимость реализации компонента «New Tab Page» («Новая вкладка») браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю оказать влияние на доступность данных или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06118
Уязвимость реализации функции автозаполнения Autofill браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06119
Уязвимость библиотеки ANGLE браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06120
Уязвимость загрузчика браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-04-03
BDU:2021-06132
Уязвимость обработчика JavaScript-сценариев V8 браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код
Modified: 2024-04-03
BDU:2021-06136
Уязвимость библиотеки ANGLE браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06137
Уязвимость компонента автодополнения Autofill браузера Google Chrome, позволяющая нарушителю оказать воздействие на конфиденциальность и целостность защищаемой информации
Modified: 2024-04-03
BDU:2021-06151
Уязвимость расширения Window Manager браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код
Modified: 2024-04-03
BDU:2021-06157
Уязвимость набора инструментов для веб-разработки DevTools браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06163
Уязвимость функции захват экрана (Screen Capture) браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06243
Уязвимость библиотеки SwiftShader браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06244
Уязвимость библиотеки SwiftShader браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06260
Уязвимость библиотеки ANGLE браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06261
Уязвимость компонента loader браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2021-06276
Уязвимость библиотеки передачи сообщений Mojo браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-24
BDU:2021-06277
Уязвимость обработчика JavaScript-сценариев V8 браузеров Microsoft Edge и Google Chrome, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-04-03
BDU:2022-00081
Уязвимость интерфейса API браузера Google Chrome, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-04-03
BDU:2022-00082
Уязвимость расширения WebRTC браузера Google Chrome, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-04-03
BDU:2022-00091
Уязвимость обработчика JavaScript-сценариев V8 браузера Google Chrome, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2023-04665
Уязвимость библиотеки ANGLE браузера Google Chrome, позволяющая нарушителю выполнить чтение и запись произвольных файлов в системе
Modified: 2024-11-21
CVE-2021-4052
Use after free in web apps in Google Chrome prior to 96.0.4664.93 allowed an attacker who convinced a user to install a malicious extension to potentially exploit heap corruption via a crafted Chrome Extension.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1267661
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1267661
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4053
Use after free in UI in Google Chrome on Linux prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1267791
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1267791
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4054
Incorrect security UI in autofill in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to perform domain spoofing via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1239760
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1239760
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4055
Heap buffer overflow in extensions in Google Chrome prior to 96.0.4664.93 allowed an attacker who convinced a user to install a malicious extension to potentially exploit heap corruption via a crafted Chrome Extension.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1266510
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1266510
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4056
Type confusion in loader in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1260939
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1260939
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4057
Use after free in file API in Google Chrome prior to 96.0.4664.93 allowed a remote attacker who had compromised the renderer process to potentially exploit heap corruption via a crafted HTML page.
- http://packetstormsecurity.com/files/165486/Chrome-storage-BlobURLStoreImpl-Revoke-Heap-Use-After-Free.html
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1262183
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- http://packetstormsecurity.com/files/165486/Chrome-storage-BlobURLStoreImpl-Revoke-Heap-Use-After-Free.html
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1262183
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4058
Heap buffer overflow in ANGLE in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1267496
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1267496
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4059
Insufficient data validation in loader in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to leak cross-origin data via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1270990
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1270990
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4061
Type confusion in V8 in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1271456
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1271456
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4062
Heap buffer overflow in BFCache in Google Chrome prior to 96.0.4664.93 allowed a remote attacker who had compromised the renderer process to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1272403
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1272403
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4063
Use after free in developer tools in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1273176
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1273176
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4064
Use after free in screen capture in Google Chrome on ChromeOS prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1273197
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1273197
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4065
Use after free in autofill in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1273674
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1273674
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4066
Integer underflow in ANGLE in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1274499
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1274499
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4067
Use after free in window manager in Google Chrome on ChromeOS prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1274641
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1274641
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4068
Insufficient data validation in new tab page in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to leak cross-origin data via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1265197
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1265197
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3W46HRT2UVHWSLZB6JZHQF6JNQWKV744/
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4078
Type confusion in V8 in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1268738
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1268738
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4079
Out of bounds write in WebRTC in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to potentially exploit heap corruption via crafted WebRTC packets.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1265806
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1265806
- https://security.gentoo.org/glsa/202208-25
- https://www.debian.org/security/2022/dsa-5046
Modified: 2024-11-21
CVE-2021-4098
Insufficient data validation in Mojo in Google Chrome prior to 96.0.4664.110 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page.
Modified: 2024-11-21
CVE-2021-4099
Use after free in Swiftshader in Google Chrome prior to 96.0.4664.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
Modified: 2024-11-21
CVE-2021-4100
Object lifecycle issue in ANGLE in Google Chrome prior to 96.0.4664.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
Modified: 2024-11-21
CVE-2021-4101
Heap buffer overflow in Swiftshader in Google Chrome prior to 96.0.4664.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
Modified: 2025-10-24
CVE-2021-4102
Use after free in V8 in Google Chrome prior to 96.0.4664.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop_13.html
- https://crbug.com/1278387
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop_13.html
- https://crbug.com/1278387
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-4102
Modified: 2024-11-21
CVE-2021-4317
Use after free in ANGLE in Google Chrome prior to 96.0.4664.93 allowed a remote attacker to perform arbitrary read/write via a crafted HTML page. (Chromium security severity: High)
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1260783
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PQKT7EGDD2P3L7S3NXEDDRCPK4NNZNWJ/
- https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop.html
- https://crbug.com/1260783
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PQKT7EGDD2P3L7S3NXEDDRCPK4NNZNWJ/
Closed vulnerabilities
Modified: 2023-11-21
BDU:2021-05969
Уязвимость компонента JNDI библиотеки журналирования Java-программ Apache Log4j2, позволяющая нарушителю выполнить произвольный код
Modified: 2026-02-20
CVE-2021-44228
Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.
- http://packetstormsecurity.com/files/165225/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165260/VMware-Security-Advisory-2021-0028.html
- http://packetstormsecurity.com/files/165261/Apache-Log4j2-2.14.1-Information-Disclosure.html
- http://packetstormsecurity.com/files/165270/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165281/Log4j2-Log4Shell-Regexes.html
- http://packetstormsecurity.com/files/165282/Log4j-Payload-Generator.html
- http://packetstormsecurity.com/files/165306/L4sh-Log4j-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165307/Log4j-Remote-Code-Execution-Word-Bypassing.html
- http://packetstormsecurity.com/files/165311/log4j-scan-Extensive-Scanner.html
- http://packetstormsecurity.com/files/165371/VMware-Security-Advisory-2021-0028.4.html
- http://packetstormsecurity.com/files/165532/Log4Shell-HTTP-Header-Injection.html
- http://packetstormsecurity.com/files/165642/VMware-vCenter-Server-Unauthenticated-Log4Shell-JNDI-Injection-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165673/UniFi-Network-Application-Unauthenticated-Log4Shell-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/167794/Open-Xchange-App-Suite-7.10.x-Cross-Site-Scripting-Command-Injection.html
- http://packetstormsecurity.com/files/167917/MobileIron-Log4Shell-Remote-Command-Execution.html
- http://packetstormsecurity.com/files/171626/AD-Manager-Plus-7122-Remote-Code-Execution.html
- http://seclists.org/fulldisclosure/2022/Dec/2
- http://seclists.org/fulldisclosure/2022/Jul/11
- http://seclists.org/fulldisclosure/2022/Mar/23
- http://www.openwall.com/lists/oss-security/2021/12/10/1
- http://www.openwall.com/lists/oss-security/2021/12/10/2
- http://www.openwall.com/lists/oss-security/2021/12/10/3
- http://www.openwall.com/lists/oss-security/2021/12/13/1
- http://www.openwall.com/lists/oss-security/2021/12/13/2
- http://www.openwall.com/lists/oss-security/2021/12/14/4
- http://www.openwall.com/lists/oss-security/2021/12/15/3
- https://cert-portal.siemens.com/productcert/pdf/ssa-397453.pdf
- https://cert-portal.siemens.com/productcert/pdf/ssa-479842.pdf
- https://cert-portal.siemens.com/productcert/pdf/ssa-661247.pdf
- https://cert-portal.siemens.com/productcert/pdf/ssa-714170.pdf
- https://github.com/cisagov/log4j-affected-db
- https://github.com/cisagov/log4j-affected-db/blob/develop/SOFTWARE-LIST.md
- https://github.com/nu11secur1ty/CVE-mitre/tree/main/CVE-2021-44228
- https://lists.debian.org/debian-lts-announce/2021/12/msg00007.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/M5CSVUNV4HWZZXGOKNSK6L7RPM7BOKIB/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VU57UJDCFIASIO35GC55JMKSRXJMCDFM/
- https://logging.apache.org/log4j/2.x/security.html
- https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
- https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0032
- https://security.netapp.com/advisory/ntap-20211210-0007/
- https://support.apple.com/kb/HT213189
- https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
- https://twitter.com/kurtseifried/status/1469345530182455296
- https://www.bentley.com/en/common-vulnerability-exposure/be-2022-0001
- https://www.debian.org/security/2021/dsa-5020
- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00646.html
- https://www.kb.cert.org/vuls/id/930724
- https://www.nu11secur1ty.com/2021/12/cve-2021-44228.html
- https://www.oracle.com/security-alerts/alert-cve-2021-44228.html
- https://www.oracle.com/security-alerts/cpuapr2022.html
- https://www.oracle.com/security-alerts/cpujan2022.html
- http://packetstormsecurity.com/files/165225/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165260/VMware-Security-Advisory-2021-0028.html
- http://packetstormsecurity.com/files/165261/Apache-Log4j2-2.14.1-Information-Disclosure.html
- http://packetstormsecurity.com/files/165270/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165281/Log4j2-Log4Shell-Regexes.html
- http://packetstormsecurity.com/files/165282/Log4j-Payload-Generator.html
- http://packetstormsecurity.com/files/165306/L4sh-Log4j-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165307/Log4j-Remote-Code-Execution-Word-Bypassing.html
- http://packetstormsecurity.com/files/165311/log4j-scan-Extensive-Scanner.html
- http://packetstormsecurity.com/files/165371/VMware-Security-Advisory-2021-0028.4.html
- http://packetstormsecurity.com/files/165532/Log4Shell-HTTP-Header-Injection.html
- http://packetstormsecurity.com/files/165642/VMware-vCenter-Server-Unauthenticated-Log4Shell-JNDI-Injection-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165673/UniFi-Network-Application-Unauthenticated-Log4Shell-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/167794/Open-Xchange-App-Suite-7.10.x-Cross-Site-Scripting-Command-Injection.html
- http://packetstormsecurity.com/files/167917/MobileIron-Log4Shell-Remote-Command-Execution.html
- http://packetstormsecurity.com/files/171626/AD-Manager-Plus-7122-Remote-Code-Execution.html
- http://seclists.org/fulldisclosure/2022/Dec/2
- http://seclists.org/fulldisclosure/2022/Jul/11
- http://seclists.org/fulldisclosure/2022/Mar/23
- http://www.openwall.com/lists/oss-security/2021/12/10/1
- http://www.openwall.com/lists/oss-security/2021/12/10/2
- http://www.openwall.com/lists/oss-security/2021/12/10/3
- http://www.openwall.com/lists/oss-security/2021/12/13/1
- http://www.openwall.com/lists/oss-security/2021/12/13/2
- http://www.openwall.com/lists/oss-security/2021/12/14/4
- http://www.openwall.com/lists/oss-security/2021/12/15/3
- https://cert-portal.siemens.com/productcert/pdf/ssa-397453.pdf
- https://cert-portal.siemens.com/productcert/pdf/ssa-479842.pdf
- https://cert-portal.siemens.com/productcert/pdf/ssa-661247.pdf
- https://cert-portal.siemens.com/productcert/pdf/ssa-714170.pdf
- https://github.com/cisagov/log4j-affected-db
- https://github.com/cisagov/log4j-affected-db/blob/develop/SOFTWARE-LIST.md
- https://github.com/nu11secur1ty/CVE-mitre/tree/main/CVE-2021-44228
- https://lists.debian.org/debian-lts-announce/2021/12/msg00007.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/M5CSVUNV4HWZZXGOKNSK6L7RPM7BOKIB/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VU57UJDCFIASIO35GC55JMKSRXJMCDFM/
- https://logging.apache.org/log4j/2.x/security.html
- https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
- https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0032
- https://security.netapp.com/advisory/ntap-20211210-0007/
- https://support.apple.com/kb/HT213189
- https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
- https://twitter.com/kurtseifried/status/1469345530182455296
- https://www.bentley.com/en/common-vulnerability-exposure/be-2022-0001
- https://www.debian.org/security/2021/dsa-5020
- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00646.html
- https://www.kb.cert.org/vuls/id/930724
- https://www.nu11secur1ty.com/2021/12/cve-2021-44228.html
- https://www.oracle.com/security-alerts/alert-cve-2021-44228.html
- https://www.oracle.com/security-alerts/cpuapr2022.html
- https://www.oracle.com/security-alerts/cpujan2022.html
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-44228
Modified: 2025-10-22
GHSA-jfh8-c2jp-5v3q
Remote code injection in Log4j
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- https://github.com/apache/logging-log4j2/pull/608
- https://github.com/github/advisory-database/pull/5501
- https://cert-portal.siemens.com/productcert/pdf/ssa-397453.pdf
- https://packetstormsecurity.com/files/165673/UniFi-Network-Application-Unauthenticated-Log4Shell-Remote-Code-Execution.html
- https://packetstormsecurity.com/files/167794/Open-Xchange-App-Suite-7.10.x-Cross-Site-Scripting-Command-Injection.html
- https://packetstormsecurity.com/files/167917/MobileIron-Log4Shell-Remote-Command-Execution.html
- https://packetstormsecurity.com/files/171626/AD-Manager-Plus-7122-Remote-Code-Execution.html
- https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0032
- https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
- https://seclists.org/fulldisclosure/2022/Dec/2
- https://seclists.org/fulldisclosure/2022/Jul/11
- https://seclists.org/fulldisclosure/2022/Mar/23
- https://security.netapp.com/advisory/ntap-20211210-0007
- https://support.apple.com/kb/HT213189
- https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
- https://twitter.com/kurtseifried/status/1469345530182455296
- https://www.bentley.com/en/common-vulnerability-exposure/be-2022-0001
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-44228
- https://www.debian.org/security/2021/dsa-5020
- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00646.html
- https://www.kb.cert.org/vuls/id/930724
- https://www.nu11secur1ty.com/2021/12/cve-2021-44228.html
- https://www.oracle.com/security-alerts/alert-cve-2021-44228.html
- https://www.oracle.com/security-alerts/cpuapr2022.html
- https://www.oracle.com/security-alerts/cpujan2022.html
- https://cert-portal.siemens.com/productcert/pdf/ssa-479842.pdf
- https://cert-portal.siemens.com/productcert/pdf/ssa-661247.pdf
- https://cert-portal.siemens.com/productcert/pdf/ssa-714170.pdf
- https://github.com/advisories/GHSA-7rjr-3q55-vv33
- https://github.com/apache/logging-log4j2
- https://github.com/cisagov/log4j-affected-db
- https://github.com/cisagov/log4j-affected-db/blob/develop/SOFTWARE-LIST.md
- https://github.com/nu11secur1ty/CVE-mitre/tree/main/CVE-2021-44228
- https://github.com/tangxiaofeng7/apache-log4j-poc
- https://issues.apache.org/jira/browse/LOG4J2-3198
- https://issues.apache.org/jira/browse/LOG4J2-3201
- https://issues.apache.org/jira/browse/LOG4J2-3214
- https://issues.apache.org/jira/browse/LOG4J2-3221
- https://lists.debian.org/debian-lts-announce/2021/12/msg00007.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/M5CSVUNV4HWZZXGOKNSK6L7RPM7BOKIB
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VU57UJDCFIASIO35GC55JMKSRXJMCDFM
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/M5CSVUNV4HWZZXGOKNSK6L7RPM7BOKIB
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VU57UJDCFIASIO35GC55JMKSRXJMCDFM
- https://logging.apache.org/log4j/2.x/changes-report.html#a2.15.0
- https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLookup
- https://logging.apache.org/log4j/2.x/manual/migration.html
- https://logging.apache.org/log4j/2.x/security.html
- https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2
- http://packetstormsecurity.com/files/165225/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165260/VMware-Security-Advisory-2021-0028.html
- http://packetstormsecurity.com/files/165261/Apache-Log4j2-2.14.1-Information-Disclosure.html
- http://packetstormsecurity.com/files/165270/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165281/Log4j2-Log4Shell-Regexes.html
- http://packetstormsecurity.com/files/165282/Log4j-Payload-Generator.html
- http://packetstormsecurity.com/files/165306/L4sh-Log4j-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165307/Log4j-Remote-Code-Execution-Word-Bypassing.html
- http://packetstormsecurity.com/files/165311/log4j-scan-Extensive-Scanner.html
- http://packetstormsecurity.com/files/165371/VMware-Security-Advisory-2021-0028.4.html
- http://packetstormsecurity.com/files/165532/Log4Shell-HTTP-Header-Injection.html
- http://packetstormsecurity.com/files/165642/VMware-vCenter-Server-Unauthenticated-Log4Shell-JNDI-Injection-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/165673/UniFi-Network-Application-Unauthenticated-Log4Shell-Remote-Code-Execution.html
- http://packetstormsecurity.com/files/167794/Open-Xchange-App-Suite-7.10.x-Cross-Site-Scripting-Command-Injection.html
- http://packetstormsecurity.com/files/167917/MobileIron-Log4Shell-Remote-Command-Execution.html
- http://packetstormsecurity.com/files/171626/AD-Manager-Plus-7122-Remote-Code-Execution.html
- http://seclists.org/fulldisclosure/2022/Dec/2
- http://seclists.org/fulldisclosure/2022/Jul/11
- http://seclists.org/fulldisclosure/2022/Mar/23
- http://www.openwall.com/lists/oss-security/2021/12/10/1
- http://www.openwall.com/lists/oss-security/2021/12/10/2
- http://www.openwall.com/lists/oss-security/2021/12/10/3
- http://www.openwall.com/lists/oss-security/2021/12/13/1
- http://www.openwall.com/lists/oss-security/2021/12/13/2
- http://www.openwall.com/lists/oss-security/2021/12/14/4
- http://www.openwall.com/lists/oss-security/2021/12/15/3
Modified: 2021-12-14
GHSA-mf4f-j588-5xm8
Apache Log4j Remote Code Execution
- https://github.com/opencast/opencast/security/advisories/GHSA-mf4f-j588-5xm8
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- https://github.com/opencast/opencast/pull/3253
- https://docs.opencast.org/r/10.x/admin/#changelog/#opencast-106
- https://docs.opencast.org/r/9.x/admin/#changelog/#opencast-910
- https://github.com/opencast/opencast
Package kernel-image-mp updated to version 5.15.8-alt1 for branch sisyphus in task 291937.
Closed vulnerabilities
Modified: 2026-01-20
BDU:2022-00095
Уязвимость реализации функций close() и fget() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-11-07
BDU:2022-00828
Уязвимость функции postclose() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-13
BDU:2022-04266
Уязвимость функции nci_request (net/nfc/nci/core.c) интерфейса контроллера NFC (NCI) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-09-16
BDU:2024-03691
Уязвимость функции cfg80211_change_iface() в модуле net/wireless/util.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-08-27
BDU:2024-03692
Уязвимость функции lpfc_mbx_cmpl_fc_reg_login() в модуле drivers/scsi/lpfc/lpfc_hbadisc.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04566
Уязвимость функции pch_can_rx_normal() драйвера Controller Area Network (CAN) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04567
Уязвимость функции ems_pcmcia_add_card() драйвера устройств Philips/NXP SJA1000 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04568
Уязвимость функции liteuart_remove() драйвера LiteUART ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04569
Уязвимость функции mlx4_en_try_alloc_resources() драйвера сетевых адаптеров Mellanox Technologies 1/10/40Gbit ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04570
Уязвимость функции _rtl92e_pci_disconnect() драйвера беспроводного адаптера RealTek RTL8192E ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-06491
Уязвимость функции mutex_unlock() в компоненте spi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-26
BDU:2024-06492
Уязвимость компонента pm80xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09136
Уязвимость компонента mlx5e ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-27
BDU:2024-09137
Уязвимость компонента hugetlb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09138
Уязвимость компонента mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-11
BDU:2024-09139
Уязвимость компонента mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09140
Уязвимость компонента ufs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09141
Уязвимость компонента lpfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09142
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-27
BDU:2024-09143
Уязвимость компонента usb-audio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09144
Уязвимость компонента advansys ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-09177
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09178
Уязвимость компонента selinux ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09209
Уязвимость компонента tusb6010 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09210
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09211
Уязвимость компонента tty_buffer ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09212
Уязвимость компонента tipc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09213
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09214
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09215
Уязвимость компонента perf bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-09218
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09219
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09220
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2024-11-27
BDU:2024-09221
Уязвимость компонента mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-09-05
BDU:2024-09222
Уязвимость компонента drm ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2024-11-27
BDU:2024-09223
Уязвимость компонента iavf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09225
Уязвимость компонента lpfc ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-27
BDU:2024-09226
Уязвимость компонента dpaa2-eth ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2024-11-27
BDU:2024-09227
Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09228
Уязвимость компонента ohci-tmio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09229
Уязвимость компонента gus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09230
Уязвимость компонентов sched/fair ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2024-11-27
BDU:2024-09231
Уязвимость компонента typec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09232
Уязвимость компонента hyperv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10530
Уязвимость компонента liteuart ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2024-10531
Уязвимость компонентов IB/hfi1 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2024-10573
Уязвимость компонента ethtool ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10574
Уязвимость компонента seg6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10575
Уязвимость компонента devlink ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2024-10576
Уязвимость компонента fq_pie ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10577
Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10578
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10579
Уязвимость функции hns_dsaf_ge_srst_by_port() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10580
Уязвимость компонента oss ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10581
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10582
Уязвимость компонента nfsd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10583
Уязвимость компонента nfsd ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2024-10584
Уязвимость компонента aio ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10585
Уязвимость компонента io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10586
Уязвимость компонента pm80xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10587
Уязвимость компонента AsoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-05
BDU:2024-10590
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10591
Уязвимость компонента mma8452 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10592
Уязвимость компонента kxcjk-1013 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10661
Уязвимость компонента io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10662
Уязвимость компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10663
Уязвимость компонентов powerpc/32 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10664
Уязвимость компонентов proc/vmcore ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10665
Уязвимость компонента mpt3sas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10666
Уязвимость компонента prestera ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10667
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
BDU:2024-10668
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10669
Уязвимость компонента virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10670
Уязвимость компонента spectrum ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10671
Уязвимость компонента stmmac ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10672
Уязвимость компонента sch_ets ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10673
Уязвимость компонента vlan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10727
Уязвимость компонента vdpa_sim ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10728
Уязвимость компонентов sched/scs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10729
Уязвимость компонента blk-mq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10730
Уязвимость компонентов drm/amd/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10731
Уязвимость компонента sata_fsl ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10736
Уязвимость компонента de4x5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10737
Уязвимость компонентов tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10740
Уязвимость компонента rxrpc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10745
Уязвимость компонентов net/smc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10748
Уязвимость компонентов drm/msm/a6xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10750
Уязвимость компонента kms ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10753
Уязвимость компонента kms ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10755
Уязвимость компонентов drm/msm/devfreq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10757
Уязвимость компонентов drm/msm операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10758
Уязвимость компонентов drm/msm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10763
Уязвимость компонента rxrpc ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-08-19
BDU:2024-10766
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-03662
Уязвимость функции felix_setup_mmio_filtering() модуля drivers/net/dsa/ocelot/felix.c - драйвера поддержки DSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-04359
Уязвимость функции nh_create_ipv6() модуля net/ipv4/nexthop.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04360
Уязвимость функции fib4_rule_action() модуля net/ipv4/fib_rules.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04362
Уязвимость функции rvu_mbox_init() модуля drivers/net/ethernet/marvell/octeontx2/af/rvu.c - драйвера поддержки сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-04363
Уязвимость функции cdnsp_endpoint_init() модуля drivers/usb/cdns3/cdnsp-mem.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04364
Уязвимость функции m_can_read_fifo() модуля drivers/net/can/m_can/m_can.c - драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04378
Уязвимость функции nfp_cpp_area_cache_add() модуля drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-04457
Уязвимость функции rtw_wx_read32() модуля drivers/staging/r8188eu/os_dep/ioctl_linux.c - поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04458
Уязвимость функции ethtool_set_coalesce() модуля net/ethtool/ioctl.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04459
Уязвимость функции amdgpu_get_xgmi_hive() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04460
Уязвимость функции qlcnic_83xx_add_rings() модуля drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c - драйвера поддержки сетевых адаптеров Ethernet Qlogic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04461
Уязвимость функции iwl_uefi_reduce_power_section() модуля drivers/net/wireless/intel/iwlwifi/fw/uefi.c - драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04462
Уязвимость функции nfc_genl_dump_ses_done() модуля net/nfc/netlink.c подсистемы NFC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14241
Уязвимость функции bigben_worker() модуля drivers/hid/hid-bigbenff.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-14242
Уязвимость функции liteuart_probe() модуля drivers/tty/serial/liteuart.c драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14246
Уязвимость функции mt7915_get_phy_mode() модуля drivers/net/wireless/mediatek/mt76/mt7915/mcu.c драйвера поддержки адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14247
Уязвимость функции smc_link_down_work() модуля net/smc/smc_core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2020-27820
A vulnerability was found in Linux kernel, where a use-after-frees in nouveau's postclose() handler could happen if removing device (that is not common to remove video card physically without power-off, but same happens if "unbind" the driver).
- https://bugzilla.redhat.com/show_bug.cgi?id=1901726
- https://lore.kernel.org/dri-devel/20201103194912.184413-2-jcline%40redhat.com/
- https://lore.kernel.org/dri-devel/20201103194912.184413-3-jcline%40redhat.com/
- https://lore.kernel.org/dri-devel/20201103194912.184413-4-jcline%40redhat.com/
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=1901726
- https://lore.kernel.org/dri-devel/20201103194912.184413-2-jcline%40redhat.com/
- https://lore.kernel.org/dri-devel/20201103194912.184413-3-jcline%40redhat.com/
- https://lore.kernel.org/dri-devel/20201103194912.184413-4-jcline%40redhat.com/
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2021-4083
A read-after-free memory flaw was found in the Linux kernel's garbage collection for Unix domain socket file handlers in the way users call close() and fget() simultaneously and can potentially trigger a race condition. This flaw allows a local user to crash the system or escalate their privileges on the system. This flaw affects Linux kernel versions prior to 5.16-rc4.
- https://bugzilla.redhat.com/show_bug.cgi?id=2029923
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=054aa8d439b9
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://security.netapp.com/advisory/ntap-20220217-0005/
- https://www.debian.org/security/2022/dsa-5096
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2029923
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=054aa8d439b9
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://security.netapp.com/advisory/ntap-20220217-0005/
- https://www.debian.org/security/2022/dsa-5096
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2021-4202
A use-after-free flaw was found in nci_request in net/nfc/nci/core.c in NFC Controller Interface (NCI) in the Linux kernel. This flaw could allow a local attacker with user privileges to cause a data race problem while the device is getting removed, leading to a privilege escalation problem.
- http://www.openwall.com/lists/oss-security/2022/06/01/2
- http://www.openwall.com/lists/oss-security/2022/06/04/2
- http://www.openwall.com/lists/oss-security/2022/06/07/2
- https://bugzilla.redhat.com/show_bug.cgi?id=2036682
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3e3b5dfcd16a3e254aab61bd1e8c417dd4503102
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=48b71a9e66c2eab60564b1b1c85f4928ed04e406
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=86cdf8e38792545161dbe3350a7eced558ba4d15
- https://security.netapp.com/advisory/ntap-20220513-0002/
- http://www.openwall.com/lists/oss-security/2022/06/01/2
- http://www.openwall.com/lists/oss-security/2022/06/04/2
- http://www.openwall.com/lists/oss-security/2022/06/07/2
- https://bugzilla.redhat.com/show_bug.cgi?id=2036682
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3e3b5dfcd16a3e254aab61bd1e8c417dd4503102
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=48b71a9e66c2eab60564b1b1c85f4928ed04e406
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=86cdf8e38792545161dbe3350a7eced558ba4d15
- https://security.netapp.com/advisory/ntap-20220513-0002/
Modified: 2024-12-20
CVE-2021-47181
In the Linux kernel, the following vulnerability has been resolved: usb: musb: tusb6010: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/06cfb4cb2241e704d72e3045cf4d7dfb567fbce0
- https://git.kernel.org/stable/c/14651496a3de6807a17c310f63c894ea0c5d858e
- https://git.kernel.org/stable/c/1ba7605856e05fa991d4654ac69e5ace66c767b9
- https://git.kernel.org/stable/c/28be095eb612a489705d38c210afaf1103c5f4f8
- https://git.kernel.org/stable/c/3ee15f1af17407be381bcf06a78fa60b471242dd
- https://git.kernel.org/stable/c/679eee466d0f9ffa60a2b0c6ec19be5128927f04
- https://git.kernel.org/stable/c/b3f43659eb0b9af2e6ef18a8d829374610b19e7a
- https://git.kernel.org/stable/c/f87a79c04a33ab4e5be598c7b0867e6ef193d702
- https://git.kernel.org/stable/c/06cfb4cb2241e704d72e3045cf4d7dfb567fbce0
- https://git.kernel.org/stable/c/14651496a3de6807a17c310f63c894ea0c5d858e
- https://git.kernel.org/stable/c/1ba7605856e05fa991d4654ac69e5ace66c767b9
- https://git.kernel.org/stable/c/28be095eb612a489705d38c210afaf1103c5f4f8
- https://git.kernel.org/stable/c/3ee15f1af17407be381bcf06a78fa60b471242dd
- https://git.kernel.org/stable/c/679eee466d0f9ffa60a2b0c6ec19be5128927f04
- https://git.kernel.org/stable/c/b3f43659eb0b9af2e6ef18a8d829374610b19e7a
- https://git.kernel.org/stable/c/f87a79c04a33ab4e5be598c7b0867e6ef193d702
Modified: 2025-03-21
CVE-2021-47182
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix scsi_mode_sense() buffer length handling Several problems exist with scsi_mode_sense() buffer length handling: 1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255. 2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer. Fix these 2 problems by using put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small. Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes. While at it, also fix the folowing: * Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation. * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.
Modified: 2025-11-03
CVE-2021-47183
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix link down processing to address NULL pointer dereference If an FC link down transition while PLOGIs are outstanding to fabric well known addresses, outstanding ABTS requests may result in a NULL pointer dereference. Driver unload requests may hang with repeated "2878" log messages. The Link down processing results in ABTS requests for outstanding ELS requests. The Abort WQEs are sent for the ELSs before the driver had set the link state to down. Thus the driver is sending the Abort with the expectation that an ABTS will be sent on the wire. The Abort request is stalled waiting for the link to come up. In some conditions the driver may auto-complete the ELSs thus if the link does come up, the Abort completions may reference an invalid structure. Fix by ensuring that Abort set the flag to avoid link traffic if issued due to conditions where the link failed.
- https://git.kernel.org/stable/c/04c1af683270e4709a594bb1691b8800b945035a
- https://git.kernel.org/stable/c/1854f53ccd88ad4e7568ddfafafffe71f1ceb0a6
- https://git.kernel.org/stable/c/28de48a7cea495ab48082d9ff4ef63f7cb4e563a
- https://git.kernel.org/stable/c/1854f53ccd88ad4e7568ddfafafffe71f1ceb0a6
- https://git.kernel.org/stable/c/28de48a7cea495ab48082d9ff4ef63f7cb4e563a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-01-14
CVE-2021-47184
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix NULL ptr dereference on VSI filter sync Remove the reason of null pointer dereference in sync VSI filters. Added new I40E_VSI_RELEASING flag to signalize deleting and releasing of VSI resources to sync this thread with sync filters subtask. Without this patch it is possible to start update the VSI filter list after VSI is removed, that's causing a kernel oops.
- https://git.kernel.org/stable/c/37d9e304acd903a445df8208b8a13d707902dea6
- https://git.kernel.org/stable/c/78f2a9e831f9610e3655a0be5e675e1aa2472089
- https://git.kernel.org/stable/c/87c421ab4a43433cb009fea44bbbc77f46913e1d
- https://git.kernel.org/stable/c/c30162da91327e4cdf7cd03079f096bb3654738c
- https://git.kernel.org/stable/c/e91e8427a1e1633a0261e3bb0201c836ac5b3890
- https://git.kernel.org/stable/c/f866513ead4370402428ef724b03c3312295c178
- https://git.kernel.org/stable/c/37d9e304acd903a445df8208b8a13d707902dea6
- https://git.kernel.org/stable/c/78f2a9e831f9610e3655a0be5e675e1aa2472089
- https://git.kernel.org/stable/c/87c421ab4a43433cb009fea44bbbc77f46913e1d
- https://git.kernel.org/stable/c/c30162da91327e4cdf7cd03079f096bb3654738c
- https://git.kernel.org/stable/c/e91e8427a1e1633a0261e3bb0201c836ac5b3890
- https://git.kernel.org/stable/c/f866513ead4370402428ef724b03c3312295c178
Modified: 2025-03-21
CVE-2021-47185
In the Linux kernel, the following vulnerability has been resolved: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one: Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120 In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it.
- https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61
- https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0550a1c1
- https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed
- https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725
- https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d
- https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41
- https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc
- https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063
- https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61
- https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0550a1c1
- https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed
- https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725
- https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d
- https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41
- https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc
- https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063
Modified: 2025-03-04
CVE-2021-47186
In the Linux kernel, the following vulnerability has been resolved: tipc: check for null after calling kmemdup kmemdup can return a null pointer so need to check for it, otherwise the null key will be dereferenced later in tipc_crypto_key_xmit as can be seen in the trace [1]. [1] https://syzkaller.appspot.com/bug?id=bca180abb29567b189efdbdb34cbf7ba851c2a58
- https://git.kernel.org/stable/c/3e6db079751afd527bf3db32314ae938dc571916
- https://git.kernel.org/stable/c/9404c4145542c23019a80ab1bb2ecf73cd057b10
- https://git.kernel.org/stable/c/a7d91625863d4ffed63b993b5e6dc1298b6430c9
- https://git.kernel.org/stable/c/3e6db079751afd527bf3db32314ae938dc571916
- https://git.kernel.org/stable/c/9404c4145542c23019a80ab1bb2ecf73cd057b10
- https://git.kernel.org/stable/c/a7d91625863d4ffed63b993b5e6dc1298b6430c9
Modified: 2025-03-21
CVE-2021-47187
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency The entry/exit latency and minimum residency in state for the idle states of MSM8998 were ..bad: first of all, for all of them the timings were written for CPU sleep but the min-residency-us param was miscalculated (supposedly, while porting this from downstream); Then, the power collapse states are setting PC on both the CPU cluster *and* the L2 cache, which have different timings: in the specific case of L2 the times are higher so these ones should be taken into account instead of the CPU ones. This parameter misconfiguration was not giving particular issues because on MSM8998 there was no CPU scaling at all, so cluster/L2 power collapse was rarely (if ever) hit. When CPU scaling is enabled, though, the wrong timings will produce SoC unstability shown to the user as random, apparently error-less, sudden reboots and/or lockups. This set of parameters are stabilizing the SoC when CPU scaling is ON and when power collapse is frequently hit.
- https://git.kernel.org/stable/c/118c826ef8b43efe0fda8faf419673707ee8c5e5
- https://git.kernel.org/stable/c/3f1dcaff642e75c1d2ad03f783fa8a3b1f56dd50
- https://git.kernel.org/stable/c/a14d7038ea201c5526375becfc43b9ba281b1e82
- https://git.kernel.org/stable/c/e52fecdd0c142b95c720683885b06ee3f0e065c8
- https://git.kernel.org/stable/c/118c826ef8b43efe0fda8faf419673707ee8c5e5
- https://git.kernel.org/stable/c/3f1dcaff642e75c1d2ad03f783fa8a3b1f56dd50
- https://git.kernel.org/stable/c/a14d7038ea201c5526375becfc43b9ba281b1e82
- https://git.kernel.org/stable/c/e52fecdd0c142b95c720683885b06ee3f0e065c8
Modified: 2025-03-04
CVE-2021-47188
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Improve SCSI abort handling The following has been observed on a test setup: WARNING: CPU: 4 PID: 250 at drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c Call trace: ufshcd_queuecommand+0x468/0x65c scsi_send_eh_cmnd+0x224/0x6a0 scsi_eh_test_devices+0x248/0x418 scsi_eh_ready_devs+0xc34/0xe58 scsi_error_handler+0x204/0x80c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 That warning is triggered by the following statement: WARN_ON(lrbp->cmd); Fix this warning by clearing lrbp->cmd from the abort handler.
Modified: 2025-04-30
CVE-2021-47189
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix memory ordering between normal and ordered work functions
Ordered work functions aren't guaranteed to be handled by the same thread
which executed the normal work functions. The only way execution between
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
unfortunately the used bitops don't guarantee any ordering whatsoever.
This manifested as seemingly inexplicable crashes on ARM64, where
async_chunk::inode is seen as non-null in async_cow_submit which causes
submit_compressed_extents to be called and crash occurs because
async_chunk::inode suddenly became NULL. The call trace was similar to:
pc : submit_compressed_extents+0x38/0x3d0
lr : async_cow_submit+0x50/0xd0
sp : ffff800015d4bc20
- https://git.kernel.org/stable/c/45da9c1767ac31857df572f0a909fbe88fd5a7e9
- https://git.kernel.org/stable/c/47e6f9f69153247109042010f3a77579e9dc61ff
- https://git.kernel.org/stable/c/637d652d351fd4f263ef302dc52f3971d314e500
- https://git.kernel.org/stable/c/670f6b3867c8f0f11e5097f353b164cecfec6179
- https://git.kernel.org/stable/c/6adbc07ebcaf8bead08b21687d49e0fc94400987
- https://git.kernel.org/stable/c/804a9d239ae9cbe88e861a7cd62319cc6ec7b136
- https://git.kernel.org/stable/c/bd660a20fea3ec60a49709ef5360f145ec0fe779
- https://git.kernel.org/stable/c/ed058d735a70f4b063323f1a7bb33cda0f987513
- https://git.kernel.org/stable/c/45da9c1767ac31857df572f0a909fbe88fd5a7e9
- https://git.kernel.org/stable/c/47e6f9f69153247109042010f3a77579e9dc61ff
- https://git.kernel.org/stable/c/637d652d351fd4f263ef302dc52f3971d314e500
- https://git.kernel.org/stable/c/670f6b3867c8f0f11e5097f353b164cecfec6179
- https://git.kernel.org/stable/c/6adbc07ebcaf8bead08b21687d49e0fc94400987
- https://git.kernel.org/stable/c/804a9d239ae9cbe88e861a7cd62319cc6ec7b136
- https://git.kernel.org/stable/c/bd660a20fea3ec60a49709ef5360f145ec0fe779
- https://git.kernel.org/stable/c/ed058d735a70f4b063323f1a7bb33cda0f987513
Modified: 2025-01-07
CVE-2021-47190
In the Linux kernel, the following vulnerability has been resolved: perf bpf: Avoid memory leak from perf_env__insert_btf() perf_env__insert_btf() doesn't insert if a duplicate BTF id is encountered and this causes a memory leak. Modify the function to return a success/error value and then free the memory if insertion didn't happen. v2. Adds a return -1 when the insertion error occurs in perf_env__fetch_btf. This doesn't affect anything as the result is never checked.
- https://git.kernel.org/stable/c/11589d3144bc4e272e0aae46ce8156162e99babc
- https://git.kernel.org/stable/c/4924b1f7c46711762fd0e65c135ccfbcfd6ded1f
- https://git.kernel.org/stable/c/642fc22210a5e59d40b1e4d56d21ec3effd401f2
- https://git.kernel.org/stable/c/ab7c3d8d81c511ddfb27823fb07081c96422b56e
- https://git.kernel.org/stable/c/11589d3144bc4e272e0aae46ce8156162e99babc
- https://git.kernel.org/stable/c/4924b1f7c46711762fd0e65c135ccfbcfd6ded1f
- https://git.kernel.org/stable/c/642fc22210a5e59d40b1e4d56d21ec3effd401f2
- https://git.kernel.org/stable/c/ab7c3d8d81c511ddfb27823fb07081c96422b56e
Modified: 2025-01-14
CVE-2021-47191
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix out-of-bound read in resp_readcap16() The following warning was observed running syzkaller: [ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in; [ 3813.830724] program syz-executor not setting count and/or reply_len properly [ 3813.836956] ================================================================== [ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0 [ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549 [ 3813.846612] Call Trace: [ 3813.846995] dump_stack+0x108/0x15f [ 3813.847524] print_address_description+0xa5/0x372 [ 3813.848243] kasan_report.cold+0x236/0x2a8 [ 3813.849439] check_memory_region+0x240/0x270 [ 3813.850094] memcpy+0x30/0x80 [ 3813.850553] sg_copy_buffer+0x157/0x1e0 [ 3813.853032] sg_copy_from_buffer+0x13/0x20 [ 3813.853660] fill_from_dev_buffer+0x135/0x370 [ 3813.854329] resp_readcap16+0x1ac/0x280 [ 3813.856917] schedule_resp+0x41f/0x1630 [ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0 [ 3813.862699] scsi_dispatch_cmd+0x330/0x950 [ 3813.863329] scsi_request_fn+0xd8e/0x1710 [ 3813.863946] __blk_run_queue+0x10b/0x230 [ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400 [ 3813.865220] sg_common_write.isra.0+0xe61/0x2420 [ 3813.871637] sg_write+0x6c8/0xef0 [ 3813.878853] __vfs_write+0xe4/0x800 [ 3813.883487] vfs_write+0x17b/0x530 [ 3813.884008] ksys_write+0x103/0x270 [ 3813.886268] __x64_sys_write+0x77/0xc0 [ 3813.886841] do_syscall_64+0x106/0x360 [ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9 This issue can be reproduced with the following syzkaller log: r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0) r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f0000000000)='fd/3\x00') open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000) r2 = syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782) write$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126) In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This leads to OOB in sg_copy_buffer(). To solve this issue, define alloc_len as u32.
- https://git.kernel.org/stable/c/3e20cb072679bdb47747ccc8bee3233a4cf0765a
- https://git.kernel.org/stable/c/4e3ace0051e7e504b55d239daab8789dd89b863c
- https://git.kernel.org/stable/c/5b8bed6464ad6653586e30df046185fd816ad999
- https://git.kernel.org/stable/c/3e20cb072679bdb47747ccc8bee3233a4cf0765a
- https://git.kernel.org/stable/c/4e3ace0051e7e504b55d239daab8789dd89b863c
- https://git.kernel.org/stable/c/5b8bed6464ad6653586e30df046185fd816ad999
Modified: 2025-04-30
CVE-2021-47192
In the Linux kernel, the following vulnerability has been resolved: scsi: core: sysfs: Fix hang when device state is set via sysfs This fixes a regression added with: commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device") The problem is that after iSCSI recovery, iscsid will call into the kernel to set the dev's state to running, and with that patch we now call scsi_rescan_device() with the state_mutex held. If the SCSI error handler thread is just starting to test the device in scsi_send_eh_cmnd() then it's going to try to grab the state_mutex. We are then stuck, because when scsi_rescan_device() tries to send its I/O scsi_queue_rq() calls -> scsi_host_queue_ready() -> scsi_host_in_recovery() which will return true (the host state is still in recovery) and I/O will just be requeued. scsi_send_eh_cmnd() will then never be able to grab the state_mutex to finish error handling. To prevent the deadlock move the rescan-related code to after we drop the state_mutex. This also adds a check for if we are already in the running state. This prevents extra scans and helps the iscsid case where if the transport class has already onlined the device during its recovery process then we don't need userspace to do it again plus possibly block that daemon.
- https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f
- https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73
- https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8
- https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27
- https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f
- https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73
- https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8
- https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27
Modified: 2025-11-03
CVE-2021-47193
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Fix memory leak during rmmod Driver failed to release all memory allocated. This would lead to memory leak during driver removal. Properly free memory when the module is removed.
- https://git.kernel.org/stable/c/0c4398f2ee030d5753f6b0ad83f0ed9077851d9a
- https://git.kernel.org/stable/c/269a4311b15f68d24e816f43f123888f241ed13d
- https://git.kernel.org/stable/c/51e6ed83bb4ade7c360551fa4ae55c4eacea354b
- https://git.kernel.org/stable/c/269a4311b15f68d24e816f43f123888f241ed13d
- https://git.kernel.org/stable/c/51e6ed83bb4ade7c360551fa4ae55c4eacea354b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2024-11-21
CVE-2021-47194
In the Linux kernel, the following vulnerability has been resolved: cfg80211: call cfg80211_stop_ap when switch from P2P_GO type If the userspace tools switch from NL80211_IFTYPE_P2P_GO to NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it does not call the cleanup cfg80211_stop_ap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assigned_chanctx_list while it is still an element of assigned_vifs list, and makes that linked list corrupt.
- https://git.kernel.org/stable/c/0738cdb636c21ab552eaecf905efa4a6070e3ebc
- https://git.kernel.org/stable/c/4e458abbb4a523f1413bfe15c079cf4e24c15b21
- https://git.kernel.org/stable/c/52affc201fc22a1ab9a59ef0ed641a9adfcb8d13
- https://git.kernel.org/stable/c/563fbefed46ae4c1f70cffb8eb54c02df480b2c2
- https://git.kernel.org/stable/c/5a9b671c8d74a3e1b999e7a0c7f366079bcc93dd
- https://git.kernel.org/stable/c/7b97b5776daa0b39dbdadfea176f9cc0646d4a66
- https://git.kernel.org/stable/c/8f06bb8c216bcd172394f61e557727e691b4cb24
- https://git.kernel.org/stable/c/b8a045e2a9b234cfbc06cf36923886164358ddec
- https://git.kernel.org/stable/c/0738cdb636c21ab552eaecf905efa4a6070e3ebc
- https://git.kernel.org/stable/c/4e458abbb4a523f1413bfe15c079cf4e24c15b21
- https://git.kernel.org/stable/c/52affc201fc22a1ab9a59ef0ed641a9adfcb8d13
- https://git.kernel.org/stable/c/563fbefed46ae4c1f70cffb8eb54c02df480b2c2
- https://git.kernel.org/stable/c/5a9b671c8d74a3e1b999e7a0c7f366079bcc93dd
- https://git.kernel.org/stable/c/7b97b5776daa0b39dbdadfea176f9cc0646d4a66
- https://git.kernel.org/stable/c/8f06bb8c216bcd172394f61e557727e691b4cb24
- https://git.kernel.org/stable/c/b8a045e2a9b234cfbc06cf36923886164358ddec
Modified: 2024-11-21
CVE-2021-47195
In the Linux kernel, the following vulnerability has been resolved: spi: fix use-after-free of the add_lock mutex Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") introduced a per-controller mutex. But mutex_unlock() of said lock is called after the controller is already freed: spi_unregister_controller(ctlr) -> put_device(&ctlr->dev) -> spi_controller_release(dev) -> mutex_unlock(&ctrl->add_lock) Move the put_device() after the mutex_unlock().
- https://git.kernel.org/stable/c/11eab327a2a8bd36c38afbff920ae1bd45588dd4
- https://git.kernel.org/stable/c/37330f37f6666c7739a44b2b6b95b047ccdbed2d
- https://git.kernel.org/stable/c/54c2c96eafcfd242e52e932ab54ace4784efe1dd
- https://git.kernel.org/stable/c/6c53b45c71b4920b5e62f0ea8079a1da382b9434
- https://git.kernel.org/stable/c/37330f37f6666c7739a44b2b6b95b047ccdbed2d
- https://git.kernel.org/stable/c/6c53b45c71b4920b5e62f0ea8079a1da382b9434
Modified: 2025-03-04
CVE-2021-47196
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Set send and receive CQ before forwarding to the driver Preset both receive and send CQ pointers prior to call to the drivers and overwrite it later again till the mlx4 is going to be changed do not overwrite ibqp properties. This change is needed for mlx5, because in case of QP creation failure, it will go to the path of QP destroy which relies on proper CQ pointers. BUG: KASAN: use-after-free in create_qp.cold+0x164/0x16e [mlx5_ib] Write of size 8 at addr ffff8880064c55c0 by task a.out/246 CPU: 0 PID: 246 Comm: a.out Not tainted 5.15.0+ #291 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x83/0xdf create_qp.cold+0x164/0x16e [mlx5_ib] mlx5_ib_create_qp+0x358/0x28a0 [mlx5_ib] create_qp.part.0+0x45b/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 246: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0xa4/0xd0 create_qp.part.0+0x92/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 246: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x10c/0x150 slab_free_freelist_hook+0xb4/0x1b0 kfree+0xe7/0x2a0 create_qp.part.0+0x52b/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae
Modified: 2025-03-21
CVE-2021-47197
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: nullify cq->dbg pointer in mlx5_debug_cq_remove() Prior to this patch in case mlx5_core_destroy_cq() failed it proceeds to rest of destroy operations. mlx5_core_destroy_cq() could be called again by user and cause additional call of mlx5_debug_cq_remove(). cq->dbg was not nullify in previous call and cause the crash. Fix it by nullify cq->dbg pointer after removal. Also proceed to destroy operations only if FW return 0 for MLX5_CMD_OP_DESTROY_CQ command. general protection fault, probably for non-canonical address 0x2000300004058: 0000 [#1] SMP PTI CPU: 5 PID: 1228 Comm: python Not tainted 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockref_get+0x1/0x60 Code: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 02 00 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 <48> 8b 17 48 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48 RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206 RAX: 0000000000000000 RBX: ffff888107d5f458 RCX: 00000000fffffffe RDX: 000000000002c2b0 RSI: ffffffff8155e2e0 RDI: 0002000300004058 RBP: ffff888137dd7a88 R08: 0002000300004058 R09: ffff8881144a9f88 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881141d4000 R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0 FS: 00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b4500f4380 CR3: 0000000114f7a003 CR4: 0000000000170ea0 Call Trace: simple_recursive_removal+0x33/0x2e0 ? debugfs_remove+0x60/0x60 debugfs_remove+0x40/0x60 mlx5_debug_cq_remove+0x32/0x70 [mlx5_core] mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core] devx_obj_cleanup+0x151/0x330 [mlx5_ib] ? __pollwait+0xd0/0xd0 ? xas_load+0x5/0x70 ? xa_load+0x62/0xa0 destroy_hw_idr_uobject+0x20/0x80 [ib_uverbs] uverbs_destroy_uobject+0x3b/0x360 [ib_uverbs] uobj_destroy+0x54/0xa0 [ib_uverbs] ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs] ? uverbs_finalize_object+0xd0/0xd0 [ib_uverbs] ib_uverbs_ioctl+0xc4/0x1b0 [ib_uverbs] __x64_sys_ioctl+0x3e4/0x8e0
- https://git.kernel.org/stable/c/2ae38157080616a13a9fe3f0b4b6ec0070aa408a
- https://git.kernel.org/stable/c/471c492890557bd58f73314bb4ad85d5a8fd5026
- https://git.kernel.org/stable/c/76ded29d3fcda4928da8849ffc446ea46871c1c2
- https://git.kernel.org/stable/c/2ae38157080616a13a9fe3f0b4b6ec0070aa408a
- https://git.kernel.org/stable/c/471c492890557bd58f73314bb4ad85d5a8fd5026
- https://git.kernel.org/stable/c/76ded29d3fcda4928da8849ffc446ea46871c1c2
Modified: 2025-01-10
CVE-2021-47198
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine An error is detected with the following report when unloading the driver: "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b" The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the flag is not cleared upon completion of the login. This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set to LPFC_RPI_ALLOW_ERROR. This results in a use after free access when used as an rpi_ids array index. Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in lpfc_mbx_cmpl_fc_reg_login().
Modified: 2025-01-14
CVE-2021-47199
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT, Fix multiple allocations and memleak of mod acts CT clear action offload adds additional mod hdr actions to the flow's original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it. Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached. Also the driver never releases the allocated mod hdr actions and causing a memleak. Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put(). backtrace: [<000000007316e2f3>] krealloc+0x83/0xd0 [<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core] [<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core] [<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core] [<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core] [<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core] [<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core] [<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core] [<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core] [<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]
Modified: 2025-01-07
CVE-2021-47200
In the Linux kernel, the following vulnerability has been resolved: drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero."
Modified: 2025-03-27
CVE-2021-47201
In the Linux kernel, the following vulnerability has been resolved: iavf: free q_vectors before queues in iavf_disable_vf iavf_free_queues() clears adapter->num_active_queues, which iavf_free_q_vectors() relies on, so swap the order of these two function calls in iavf_disable_vf(). This resolves a panic encountered when the interface is disabled and then later brought up again after PF communication is restored.
- https://git.kernel.org/stable/c/78638b47132244e3934dc5dc79f6372d5ce8e98c
- https://git.kernel.org/stable/c/89f22f129696ab53cfbc608e0a2184d0fea46ac1
- https://git.kernel.org/stable/c/926e8c83d4c1c2dac0026637eb0d492df876489e
- https://git.kernel.org/stable/c/9ef6589cac9a8c47f5544ccdf4c498093733bb3f
- https://git.kernel.org/stable/c/78638b47132244e3934dc5dc79f6372d5ce8e98c
- https://git.kernel.org/stable/c/89f22f129696ab53cfbc608e0a2184d0fea46ac1
- https://git.kernel.org/stable/c/926e8c83d4c1c2dac0026637eb0d492df876489e
- https://git.kernel.org/stable/c/9ef6589cac9a8c47f5544ccdf4c498093733bb3f
Modified: 2025-03-27
CVE-2021-47203
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq() When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "fail_msg" string is set and a log message output. The job is then added to a completions list for cancellation. Processing of any further jobs from the txq list continues, but since "fail_msg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption. Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure.
- https://git.kernel.org/stable/c/16bcbfb56d759c25665f786e33ec633b9508a08f
- https://git.kernel.org/stable/c/814d3610c4ce86e8cf285b2cdac0057a42e82de5
- https://git.kernel.org/stable/c/99154581b05c8fb22607afb7c3d66c1bace6aa5d
- https://git.kernel.org/stable/c/ad4776b5eb2e58af1226847fcd3b4f6d051674dd
- https://git.kernel.org/stable/c/b291d147d0268e93ad866f8bc820ea14497abc9b
- https://git.kernel.org/stable/c/c097bd5a59162156d9c2077a2f58732ffbaa9fca
- https://git.kernel.org/stable/c/ec70d80a8642900086447ba0cdc79e3f44d42e8f
- https://git.kernel.org/stable/c/f05a0191b90156e539cccc189b9d87ca2a4d9305
- https://git.kernel.org/stable/c/16bcbfb56d759c25665f786e33ec633b9508a08f
- https://git.kernel.org/stable/c/814d3610c4ce86e8cf285b2cdac0057a42e82de5
- https://git.kernel.org/stable/c/99154581b05c8fb22607afb7c3d66c1bace6aa5d
- https://git.kernel.org/stable/c/ad4776b5eb2e58af1226847fcd3b4f6d051674dd
- https://git.kernel.org/stable/c/b291d147d0268e93ad866f8bc820ea14497abc9b
- https://git.kernel.org/stable/c/c097bd5a59162156d9c2077a2f58732ffbaa9fca
- https://git.kernel.org/stable/c/ec70d80a8642900086447ba0cdc79e3f44d42e8f
- https://git.kernel.org/stable/c/f05a0191b90156e539cccc189b9d87ca2a4d9305
Modified: 2025-01-14
CVE-2021-47204
In the Linux kernel, the following vulnerability has been resolved: net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove Access to netdev after free_netdev() will cause use-after-free bug. Move debug log before free_netdev() call to avoid it.
- https://git.kernel.org/stable/c/1c4099dc0d6a01e76e4f7dd98e4b3e0d55d80ad9
- https://git.kernel.org/stable/c/32d4686224744819ddcae58b666c21d2a4ef4c88
- https://git.kernel.org/stable/c/9b5a333272a48c2f8b30add7a874e46e8b26129c
- https://git.kernel.org/stable/c/d74ff10ed2d93dc9b67e99a74b36fb9a83273d8a
- https://git.kernel.org/stable/c/1c4099dc0d6a01e76e4f7dd98e4b3e0d55d80ad9
- https://git.kernel.org/stable/c/32d4686224744819ddcae58b666c21d2a4ef4c88
- https://git.kernel.org/stable/c/9b5a333272a48c2f8b30add7a874e46e8b26129c
- https://git.kernel.org/stable/c/d74ff10ed2d93dc9b67e99a74b36fb9a83273d8a
Modified: 2025-03-04
CVE-2021-47205
In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: Unregister clocks/resets when unbinding Currently, unbinding a CCU driver unmaps the device's MMIO region, while leaving its clocks/resets and their providers registered. This can cause a page fault later when some clock operation tries to perform MMIO. Fix this by separating the CCU initialization from the memory allocation, and then using a devres callback to unregister the clocks and resets. This also fixes a memory leak of the `struct ccu_reset`, and uses the correct owner (the specific platform driver) for the clocks and resets. Early OF clock providers are never unregistered, and limited error handling is possible, so they are mostly unchanged. The error reporting is made more consistent by moving the message inside of_sunxi_ccu_probe.
Modified: 2025-01-07
CVE-2021-47206
In the Linux kernel, the following vulnerability has been resolved: usb: host: ohci-tmio: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/065334f6640d074a1caec2f8b0091467a22f9483
- https://git.kernel.org/stable/c/2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100
- https://git.kernel.org/stable/c/28e016e02118917e50a667bc72fb80098cf2b460
- https://git.kernel.org/stable/c/2f18f97a1a787154a372c0738f1576f14b693d91
- https://git.kernel.org/stable/c/951b8239fd24678b56c995c5c0456ab12e059d19
- https://git.kernel.org/stable/c/9eff2b2e59fda25051ab36cd1cb5014661df657b
- https://git.kernel.org/stable/c/bb6ed2e05eb6e8619b30fa854f9becd50c11723f
- https://git.kernel.org/stable/c/f98986b7acb4219f95789095eced93ed69d81d35
- https://git.kernel.org/stable/c/065334f6640d074a1caec2f8b0091467a22f9483
- https://git.kernel.org/stable/c/2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100
- https://git.kernel.org/stable/c/28e016e02118917e50a667bc72fb80098cf2b460
- https://git.kernel.org/stable/c/2f18f97a1a787154a372c0738f1576f14b693d91
- https://git.kernel.org/stable/c/951b8239fd24678b56c995c5c0456ab12e059d19
- https://git.kernel.org/stable/c/9eff2b2e59fda25051ab36cd1cb5014661df657b
- https://git.kernel.org/stable/c/bb6ed2e05eb6e8619b30fa854f9becd50c11723f
- https://git.kernel.org/stable/c/f98986b7acb4219f95789095eced93ed69d81d35
Modified: 2025-01-13
CVE-2021-47207
In the Linux kernel, the following vulnerability has been resolved: ALSA: gus: fix null pointer dereference on pointer block The pointer block return from snd_gf1_dma_next_block could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.
- https://git.kernel.org/stable/c/16721797dcef2c7c030ffe73a07f39a65f9323c3
- https://git.kernel.org/stable/c/1ac6cd87d8ddd36c43620f82c4d65b058f725f0f
- https://git.kernel.org/stable/c/3e28e083dcdf03a18a083f8a47b6bb6b1604b5be
- https://git.kernel.org/stable/c/542fa721594a02d2aee0370a764d306ef48d030c
- https://git.kernel.org/stable/c/a0d21bb3279476c777434c40d969ea88ca64f9aa
- https://git.kernel.org/stable/c/ab4c1ebc40f699f48346f634d7b72b9c5193f315
- https://git.kernel.org/stable/c/c6d2cefdd05c4810c416fb8d384b5c377bd977bc
- https://git.kernel.org/stable/c/cb09c760c201f82df83babc92a5ffea0a01807fc
- https://git.kernel.org/stable/c/16721797dcef2c7c030ffe73a07f39a65f9323c3
- https://git.kernel.org/stable/c/1ac6cd87d8ddd36c43620f82c4d65b058f725f0f
- https://git.kernel.org/stable/c/3e28e083dcdf03a18a083f8a47b6bb6b1604b5be
- https://git.kernel.org/stable/c/542fa721594a02d2aee0370a764d306ef48d030c
- https://git.kernel.org/stable/c/a0d21bb3279476c777434c40d969ea88ca64f9aa
- https://git.kernel.org/stable/c/ab4c1ebc40f699f48346f634d7b72b9c5193f315
- https://git.kernel.org/stable/c/c6d2cefdd05c4810c416fb8d384b5c377bd977bc
- https://git.kernel.org/stable/c/cb09c760c201f82df83babc92a5ffea0a01807fc
Modified: 2025-03-27
CVE-2021-47209
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Prevent dead task groups from regaining cfs_rq's Kevin is reporting crashes which point to a use-after-free of a cfs_rq in update_blocked_averages(). Initial debugging revealed that we've live cfs_rq's (on_list=1) in an about to be kfree()'d task group in free_fair_sched_group(). However, it was unclear how that can happen. His kernel config happened to lead to a layout of struct sched_entity that put the 'my_q' member directly into the middle of the object which makes it incidentally overlap with SLUB's freelist pointer. That, in combination with SLAB_FREELIST_HARDENED's freelist pointer mangling, leads to a reliable access violation in form of a #GP which made the UAF fail fast. Michal seems to have run into the same issue[1]. He already correctly diagnosed that commit a7b359fc6a37 ("sched/fair: Correctly insert cfs_rq's to list on unthrottle") is causing the preconditions for the UAF to happen by re-adding cfs_rq's also to task groups that have no more running tasks, i.e. also to dead ones. His analysis, however, misses the real root cause and it cannot be seen from the crash backtrace only, as the real offender is tg_unthrottle_up() getting called via sched_cfs_period_timer() via the timer interrupt at an inconvenient time. When unregister_fair_sched_group() unlinks all cfs_rq's from the dying task group, it doesn't protect itself from getting interrupted. If the timer interrupt triggers while we iterate over all CPUs or after unregister_fair_sched_group() has finished but prior to unlinking the task group, sched_cfs_period_timer() will execute and walk the list of task groups, trying to unthrottle cfs_rq's, i.e. re-add them to the dying task group. These will later -- in free_fair_sched_group() -- be kfree()'ed while still being linked, leading to the fireworks Kevin and Michal are seeing. To fix this race, ensure the dying task group gets unlinked first. However, simply switching the order of unregistering and unlinking the task group isn't sufficient, as concurrent RCU walkers might still see it, as can be seen below: CPU1: CPU2: : timer IRQ: : do_sched_cfs_period_timer(): : : : distribute_cfs_runtime(): : rcu_read_lock(); : : : unthrottle_cfs_rq(): sched_offline_group(): : : walk_tg_tree_from(…,tg_unthrottle_up,…): list_del_rcu(&tg->list); : (1) : list_for_each_entry_rcu(child, &parent->children, siblings) : : (2) list_del_rcu(&tg->siblings); : : tg_unthrottle_up(): unregister_fair_sched_group(): struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)]; : : list_del_leaf_cfs_rq(tg->cfs_rq[cpu]); : : : : if (!cfs_rq_is_decayed(cfs_rq) || cfs_rq->nr_running) (3) : list_add_leaf_cfs_rq(cfs_rq); : : : : : : : : : ---truncated---
Modified: 2025-03-27
CVE-2021-47210
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Remove WARN_ON in tps6598x_block_read Calling tps6598x_block_read with a higher than allowed len can be handled by just returning an error. There's no need to crash systems with panic-on-warn enabled.
- https://git.kernel.org/stable/c/2a897d384513ba7f7ef05611338b9a6ec6aeac00
- https://git.kernel.org/stable/c/2c71811c963b6c310a29455d521d31a7ea6c5b5e
- https://git.kernel.org/stable/c/30dcfcda8992dc42f18e7d35b6a1fa72372d382d
- https://git.kernel.org/stable/c/b7a0a63f3fed57d413bb857de164ea9c3984bc4e
- https://git.kernel.org/stable/c/eff8b7628410cb2eb562ca0d5d1f12e27063733e
- https://git.kernel.org/stable/c/2a897d384513ba7f7ef05611338b9a6ec6aeac00
- https://git.kernel.org/stable/c/2c71811c963b6c310a29455d521d31a7ea6c5b5e
- https://git.kernel.org/stable/c/30dcfcda8992dc42f18e7d35b6a1fa72372d382d
- https://git.kernel.org/stable/c/b7a0a63f3fed57d413bb857de164ea9c3984bc4e
- https://git.kernel.org/stable/c/eff8b7628410cb2eb562ca0d5d1f12e27063733e
Modified: 2025-01-14
CVE-2021-47211
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix null pointer dereference on pointer cs_desc The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.
Modified: 2025-03-27
CVE-2021-47212
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Update error handler for UCTX and UMEM In the fast unload flow, the device state is set to internal error, which indicates that the driver started the destroy process. In this case, when a destroy command is being executed, it should return MLX5_CMD_STAT_OK. Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK instead of EIO. This fixes a call trace in the umem release process - [ 2633.536695] Call Trace: [ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] [ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core] [ 2633.539641] disable_device+0x8c/0x130 [ib_core] [ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core] [ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core] [ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib] [ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary] [ 2633.544661] device_release_driver_internal+0x103/0x1f0 [ 2633.545679] bus_remove_device+0xf7/0x170 [ 2633.546640] device_del+0x181/0x410 [ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core] [ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core] [ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core] [ 2633.550864] remove_one+0x69/0xe0 [mlx5_core] [ 2633.551819] pci_device_remove+0x3b/0xc0 [ 2633.552731] device_release_driver_internal+0x103/0x1f0 [ 2633.553746] unbind_store+0xf6/0x130 [ 2633.554657] kernfs_fop_write+0x116/0x190 [ 2633.555567] vfs_write+0xa5/0x1a0 [ 2633.556407] ksys_write+0x4f/0xb0 [ 2633.557233] do_syscall_64+0x5b/0x1a0 [ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 2633.559018] RIP: 0033:0x7f9977132648 [ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 [ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648 [ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001 [ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740 [ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0 [ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c [ 2633.568725] ---[ end trace 10b4fe52945e544d ]---
Modified: 2025-03-27
CVE-2021-47214
In the Linux kernel, the following vulnerability has been resolved: hugetlb, userfaultfd: fix reservation restore on userfaultfd error Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we bail out using "goto out_release_unlock;" in the cases where idx >= size, or !huge_pte_none(), the code will detect that new_pagecache_page == false, and so call restore_reserve_on_error(). In this case I see restore_reserve_on_error() delete the reservation, and the following call to remove_inode_hugepages() will increment h->resv_hugepages causing a 100% reproducible leak. We should treat the is_continue case similar to adding a page into the pagecache and set new_pagecache_page to true, to indicate that there is no reservation to restore on the error path, and we need not call restore_reserve_on_error(). Rename new_pagecache_page to page_in_pagecache to make that clear.
Modified: 2025-03-27
CVE-2021-47215
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix crash in RX resync flow For the TLS RX resync flow, we maintain a list of TLS contexts that require some attention, to communicate their resync information to the HW. Here we fix list corruptions, by protecting the entries against movements coming from resync_handle_seq_match(), until their resync handling in napi is fully completed.
Modified: 2025-03-18
CVE-2021-47216
In the Linux kernel, the following vulnerability has been resolved: scsi: advansys: Fix kernel pointer leak Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx. Change %lx to %p to print the hashed pointer.
- https://git.kernel.org/stable/c/055eced3edf5b675d12189081303f6285ef26511
- https://git.kernel.org/stable/c/06d7d12efb5c62db9dea15141ae2b322c2719515
- https://git.kernel.org/stable/c/27490ae6a85a70242d80615ca74d0362a820d6a7
- https://git.kernel.org/stable/c/5612287991debe310c914600599bd59511ababfb
- https://git.kernel.org/stable/c/ad19f7046c24f95c674fbea21870479b2b9f5bab
- https://git.kernel.org/stable/c/cc248790bfdcf879e3094fa248c85bf92cdf9dae
- https://git.kernel.org/stable/c/d4996c6eac4c81b8872043e9391563f67f13e406
- https://git.kernel.org/stable/c/f5a0ba4a9b5e70e7b2f767636d26523f9d1ac59d
- https://git.kernel.org/stable/c/055eced3edf5b675d12189081303f6285ef26511
- https://git.kernel.org/stable/c/06d7d12efb5c62db9dea15141ae2b322c2719515
- https://git.kernel.org/stable/c/27490ae6a85a70242d80615ca74d0362a820d6a7
- https://git.kernel.org/stable/c/5612287991debe310c914600599bd59511ababfb
- https://git.kernel.org/stable/c/ad19f7046c24f95c674fbea21870479b2b9f5bab
- https://git.kernel.org/stable/c/cc248790bfdcf879e3094fa248c85bf92cdf9dae
- https://git.kernel.org/stable/c/d4996c6eac4c81b8872043e9391563f67f13e406
- https://git.kernel.org/stable/c/f5a0ba4a9b5e70e7b2f767636d26523f9d1ac59d
Modified: 2025-01-14
CVE-2021-47217
In the Linux kernel, the following vulnerability has been resolved: x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails Check for a valid hv_vp_index array prior to derefencing hv_vp_index when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all functionality. BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30
- https://git.kernel.org/stable/c/8823ea27fff6084bbb4bc71d15378fae0220b1d8
- https://git.kernel.org/stable/c/9c177eee116cf888276d3748cb176e72562cfd5c
- https://git.kernel.org/stable/c/b0e44dfb4e4c699cca33ede431b8d127e6e8d661
- https://git.kernel.org/stable/c/b20ec58f8a6f4fef32cc71480ddf824584e24743
- https://git.kernel.org/stable/c/daf972118c517b91f74ff1731417feb4270625a4
- https://git.kernel.org/stable/c/8823ea27fff6084bbb4bc71d15378fae0220b1d8
- https://git.kernel.org/stable/c/9c177eee116cf888276d3748cb176e72562cfd5c
- https://git.kernel.org/stable/c/b0e44dfb4e4c699cca33ede431b8d127e6e8d661
- https://git.kernel.org/stable/c/b20ec58f8a6f4fef32cc71480ddf824584e24743
- https://git.kernel.org/stable/c/daf972118c517b91f74ff1731417feb4270625a4
Modified: 2025-01-14
CVE-2021-47218
In the Linux kernel, the following vulnerability has been resolved: selinux: fix NULL-pointer dereference when hashtab allocation fails When the hash table slot array allocation fails in hashtab_init(), h->size is left initialized with a non-zero value, but the h->htable pointer is NULL. This may then cause a NULL pointer dereference, since the policydb code relies on the assumption that even after a failed hashtab_init(), hashtab_map() and hashtab_destroy() can be safely called on it. Yet, these detect an empty hashtab only by looking at the size. Fix this by making sure that hashtab_init() always leaves behind a valid empty hashtab when the allocation fails.
- https://git.kernel.org/stable/c/83c8ab8503adf56bf68dafc7a382f4946c87da79
- https://git.kernel.org/stable/c/b17dd53cac769dd13031b0ca34f90cc65e523fab
- https://git.kernel.org/stable/c/dc27f3c5d10c58069672215787a96b4fae01818b
- https://git.kernel.org/stable/c/83c8ab8503adf56bf68dafc7a382f4946c87da79
- https://git.kernel.org/stable/c/b17dd53cac769dd13031b0ca34f90cc65e523fab
- https://git.kernel.org/stable/c/dc27f3c5d10c58069672215787a96b4fae01818b
Modified: 2025-03-04
CVE-2021-47219
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs() The following issue was observed running syzkaller: BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline] BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815 CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe4/0x14a lib/dump_stack.c:118 print_address_description+0x73/0x280 mm/kasan/report.c:253 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report+0x272/0x370 mm/kasan/report.c:410 memcpy+0x1f/0x50 mm/kasan/kasan.c:302 memcpy include/linux/string.h:377 [inline] sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831 fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021 resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772 schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429 scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835 scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896 scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034 __blk_run_queue_uncond block/blk-core.c:464 [inline] __blk_run_queue+0x1a4/0x380 block/blk-core.c:484 blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78 sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847 sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716 sg_write+0x64/0xa0 drivers/scsi/sg.c:622 __vfs_write+0xed/0x690 fs/read_write.c:485 kill_bdev:block_device:00000000e138492c vfs_write+0x184/0x4c0 fs/read_write.c:549 ksys_write+0x107/0x240 fs/read_write.c:599 do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe We get 'alen' from command its type is int. If userspace passes a large length we will get a negative 'alen'. Switch n, alen, and rlen to u32.
- https://git.kernel.org/stable/c/66523553fa62c7878fc5441dc4e82be71934eb77
- https://git.kernel.org/stable/c/8440377e1a5644779b4c8d013aa2a917f5fc83c3
- https://git.kernel.org/stable/c/f347c26836c270199de1599c3cd466bb7747caa9
- https://git.kernel.org/stable/c/66523553fa62c7878fc5441dc4e82be71934eb77
- https://git.kernel.org/stable/c/8440377e1a5644779b4c8d013aa2a917f5fc83c3
- https://git.kernel.org/stable/c/f347c26836c270199de1599c3cd466bb7747caa9
Modified: 2025-01-06
CVE-2021-47499
In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the memory allocated by iio_triggered_buffer_setup() will not be freed, and cause memory leak as follows: unreferenced object 0xffff888009551400 (size 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ ....... backtrace: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013] Fix it by remove data->dready_trig condition in probe and remove.
- https://git.kernel.org/stable/c/14508fe13b1c578b3d2ba574f1d48b351975860c
- https://git.kernel.org/stable/c/3899700ddacbf7aaafadf44464fff3ff0d4e3307
- https://git.kernel.org/stable/c/60a55b9d91ba99eb8cf015bc46dc2de05e168a15
- https://git.kernel.org/stable/c/70c9774e180d151abaab358108e3510a8e615215
- https://git.kernel.org/stable/c/8c163a14277115ca962103910ab4cce55e862ffb
- https://git.kernel.org/stable/c/8c1d43f3a3fc7184c42d7398bdf59a2a2903e4fc
- https://git.kernel.org/stable/c/a3730f74159ad00a28960c0efe2a931fe6fe6b45
- https://git.kernel.org/stable/c/ee86d0bad80bdcd11a87e188a596727f41b62320
- https://git.kernel.org/stable/c/14508fe13b1c578b3d2ba574f1d48b351975860c
- https://git.kernel.org/stable/c/3899700ddacbf7aaafadf44464fff3ff0d4e3307
- https://git.kernel.org/stable/c/60a55b9d91ba99eb8cf015bc46dc2de05e168a15
- https://git.kernel.org/stable/c/70c9774e180d151abaab358108e3510a8e615215
- https://git.kernel.org/stable/c/8c163a14277115ca962103910ab4cce55e862ffb
- https://git.kernel.org/stable/c/8c1d43f3a3fc7184c42d7398bdf59a2a2903e4fc
- https://git.kernel.org/stable/c/a3730f74159ad00a28960c0efe2a931fe6fe6b45
- https://git.kernel.org/stable/c/ee86d0bad80bdcd11a87e188a596727f41b62320
Modified: 2025-01-06
CVE-2021-47500
In the Linux kernel, the following vulnerability has been resolved: iio: mma8452: Fix trigger reference couting The mma8452 driver directly assigns a trigger to the struct iio_dev. The IIO core when done using this trigger will call `iio_trigger_put()` to drop the reference count by 1. Without the matching `iio_trigger_get()` in the driver the reference count can reach 0 too early, the trigger gets freed while still in use and a use-after-free occurs. Fix this by getting a reference to the trigger before assigning it to the IIO device.
- https://git.kernel.org/stable/c/094d513b78b1714113bc016684b8142382e071ba
- https://git.kernel.org/stable/c/794c0898f6bf39a458655d5fb4af70ec43a5cfcb
- https://git.kernel.org/stable/c/acf0088ac073ca6e7f4cad6acac112177e08df5e
- https://git.kernel.org/stable/c/c43517071dfc9fce34f8f69dbb98a86017f6b739
- https://git.kernel.org/stable/c/cd0082235783f814241a1c9483fb89e405f4f892
- https://git.kernel.org/stable/c/db12d95085367de8b0223929d1332731024441f1
- https://git.kernel.org/stable/c/f5deab10ced368c807866283f8b79144c4823be8
- https://git.kernel.org/stable/c/fb75cc4740d81264cd5bcb0e17d961d018a8be96
- https://git.kernel.org/stable/c/094d513b78b1714113bc016684b8142382e071ba
- https://git.kernel.org/stable/c/794c0898f6bf39a458655d5fb4af70ec43a5cfcb
- https://git.kernel.org/stable/c/acf0088ac073ca6e7f4cad6acac112177e08df5e
- https://git.kernel.org/stable/c/c43517071dfc9fce34f8f69dbb98a86017f6b739
- https://git.kernel.org/stable/c/cd0082235783f814241a1c9483fb89e405f4f892
- https://git.kernel.org/stable/c/db12d95085367de8b0223929d1332731024441f1
- https://git.kernel.org/stable/c/f5deab10ced368c807866283f8b79144c4823be8
- https://git.kernel.org/stable/c/fb75cc4740d81264cd5bcb0e17d961d018a8be96
Modified: 2025-01-06
CVE-2021-47501
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc When trying to dump VFs VSI RX/TX descriptors using debugfs there was a crash due to NULL pointer dereference in i40e_dbg_dump_desc. Added a check to i40e_dbg_dump_desc that checks if VSI type is correct for dumping RX/TX descriptors.
- https://git.kernel.org/stable/c/16431e442db248ecd8aa9457cf0a656f1885f56e
- https://git.kernel.org/stable/c/23ec111bf3549aae37140330c31a16abfc172421
- https://git.kernel.org/stable/c/e5b7fb2198abc50058f1a29c395b004f76ab1c83
- https://git.kernel.org/stable/c/16431e442db248ecd8aa9457cf0a656f1885f56e
- https://git.kernel.org/stable/c/23ec111bf3549aae37140330c31a16abfc172421
- https://git.kernel.org/stable/c/e5b7fb2198abc50058f1a29c395b004f76ab1c83
Modified: 2025-09-29
CVE-2021-47502
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd934x: handle channel mappping list correctly Currently each channel is added as list to dai channel list, however there is danger of adding same channel to multiple dai channel list which endups corrupting the other list where its already added. This patch ensures that the channel is actually free before adding to the dai channel list and also ensures that the channel is on the list before deleting it. This check was missing previously, and we did not hit this issue as we were testing very simple usecases with sequence of amixer commands.
- https://git.kernel.org/stable/c/1089dac26c6b4b833323ae6c0ceab29fb30ede72
- https://git.kernel.org/stable/c/23ba28616d3063bd4c4953598ed5e439ca891101
- https://git.kernel.org/stable/c/339ffb5b56005582aacc860524d2d208604049d1
- https://git.kernel.org/stable/c/1089dac26c6b4b833323ae6c0ceab29fb30ede72
- https://git.kernel.org/stable/c/23ba28616d3063bd4c4953598ed5e439ca891101
- https://git.kernel.org/stable/c/339ffb5b56005582aacc860524d2d208604049d1
Modified: 2025-04-01
CVE-2021-47503
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Do not call scsi_remove_host() in pm8001_alloc() Calling scsi_remove_host() before scsi_add_host() results in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000108 RIP: 0010:device_del+0x63/0x440 Call Trace: device_unregister+0x17/0x60 scsi_remove_host+0xee/0x2a0 pm8001_pci_probe+0x6ef/0x1b90 [pm80xx] local_pci_probe+0x3f/0x90 We cannot call scsi_remove_host() in pm8001_alloc() because scsi_add_host() has not been called yet at that point in time. Function call tree: pm8001_pci_probe() | `- pm8001_pci_alloc() | | | `- pm8001_alloc() | | | `- scsi_remove_host() | `- scsi_add_host()
- https://git.kernel.org/stable/c/1e434d2687e8bc0b3cdc9dd093c0e9047c0b4add
- https://git.kernel.org/stable/c/653926205741add87a6cf452e21950eebc6ac10b
- https://git.kernel.org/stable/c/f8dccc1bdea7e21b5ec06c957aef8831c772661c
- https://git.kernel.org/stable/c/1e434d2687e8bc0b3cdc9dd093c0e9047c0b4add
- https://git.kernel.org/stable/c/653926205741add87a6cf452e21950eebc6ac10b
- https://git.kernel.org/stable/c/f8dccc1bdea7e21b5ec06c957aef8831c772661c
Modified: 2025-09-29
CVE-2021-47504
In the Linux kernel, the following vulnerability has been resolved: io_uring: ensure task_work gets run as part of cancelations If we successfully cancel a work item but that work item needs to be processed through task_work, then we can be sleeping uninterruptibly in io_uring_cancel_generic() and never process it. Hence we don't make forward progress and we end up with an uninterruptible sleep warning. While in there, correct a comment that should be IFF, not IIF.
Modified: 2025-01-10
CVE-2021-47505
In the Linux kernel, the following vulnerability has been resolved:
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani
- https://git.kernel.org/stable/c/321fba81ec034f88aea4898993c1bf15605c023f
- https://git.kernel.org/stable/c/4105e6a128e8a98455dfc9e6dbb2ab0c33c4497f
- https://git.kernel.org/stable/c/47ffefd88abfffe8a040bcc1dd0554d4ea6f7689
- https://git.kernel.org/stable/c/50252e4b5e989ce64555c7aef7516bdefc2fea72
- https://git.kernel.org/stable/c/60d311f9e6381d779d7d53371f87285698ecee24
- https://git.kernel.org/stable/c/321fba81ec034f88aea4898993c1bf15605c023f
- https://git.kernel.org/stable/c/4105e6a128e8a98455dfc9e6dbb2ab0c33c4497f
- https://git.kernel.org/stable/c/47ffefd88abfffe8a040bcc1dd0554d4ea6f7689
- https://git.kernel.org/stable/c/50252e4b5e989ce64555c7aef7516bdefc2fea72
- https://git.kernel.org/stable/c/60d311f9e6381d779d7d53371f87285698ecee24
Modified: 2025-01-06
CVE-2021-47506
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix use-after-free due to delegation race A delegation break could arrive as soon as we've called vfs_setlease. A delegation break runs a callback which immediately (in nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru. If we then exit nfs4_set_delegation without hashing the delegation, it will be freed as soon as the callback is done with it, without ever being removed from del_recall_lru. Symptoms show up later as use-after-free or list corruption warnings, usually in the laundromat thread. I suspect aba2072f4523 "nfsd: grant read delegations to clients holding writes" made this bug easier to hit, but I looked as far back as v3.0 and it looks to me it already had the same problem. So I'm not sure where the bug was introduced; it may have been there from the beginning.
- https://git.kernel.org/stable/c/04a8d07f3d58308b92630045560799a3faa3ebce
- https://git.kernel.org/stable/c/148c816f10fd11df27ca6a9b3238cdd42fa72cd3
- https://git.kernel.org/stable/c/2becaa990b93cbd2928292c0b669d3abb6cf06d4
- https://git.kernel.org/stable/c/33645d3e22720cac1e4548f8fef57bf0649536ee
- https://git.kernel.org/stable/c/348714018139c39533c55661a0c7c990671396b4
- https://git.kernel.org/stable/c/548ec0805c399c65ed66c6641be467f717833ab5
- https://git.kernel.org/stable/c/e0759696de6851d7536efddfdd2dfed4c4df1f09
- https://git.kernel.org/stable/c/eeb0711801f5e19ef654371b627682aed3b11373
- https://git.kernel.org/stable/c/04a8d07f3d58308b92630045560799a3faa3ebce
- https://git.kernel.org/stable/c/148c816f10fd11df27ca6a9b3238cdd42fa72cd3
- https://git.kernel.org/stable/c/2becaa990b93cbd2928292c0b669d3abb6cf06d4
- https://git.kernel.org/stable/c/33645d3e22720cac1e4548f8fef57bf0649536ee
- https://git.kernel.org/stable/c/348714018139c39533c55661a0c7c990671396b4
- https://git.kernel.org/stable/c/548ec0805c399c65ed66c6641be467f717833ab5
- https://git.kernel.org/stable/c/e0759696de6851d7536efddfdd2dfed4c4df1f09
- https://git.kernel.org/stable/c/eeb0711801f5e19ef654371b627682aed3b11373
Modified: 2025-09-24
CVE-2021-47507
In the Linux kernel, the following vulnerability has been resolved: nfsd: Fix nsfd startup race (again) Commit bd5ae9288d64 ("nfsd: register pernet ops last, unregister first") has re-opened rpc_pipefs_event() race against nfsd_net_id registration (register_pernet_subsys()) which has been fixed by commit bb7ffbf29e76 ("nfsd: fix nsfd startup race triggering BUG_ON"). Restore the order of register_pernet_subsys() vs register_cld_notifier(). Add WARN_ON() to prevent a future regression. Crash info: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000012 CPU: 8 PID: 345 Comm: mount Not tainted 5.4.144-... #1 pc : rpc_pipefs_event+0x54/0x120 [nfsd] lr : rpc_pipefs_event+0x48/0x120 [nfsd] Call trace: rpc_pipefs_event+0x54/0x120 [nfsd] blocking_notifier_call_chain rpc_fill_super get_tree_keyed rpc_fs_get_tree vfs_get_tree do_mount ksys_mount __arm64_sys_mount el0_svc_handler el0_svc
- https://git.kernel.org/stable/c/8bf902fee5893cfc2f04a698abab47629699ae9a
- https://git.kernel.org/stable/c/b10252c7ae9c9d7c90552f88b544a44ee773af64
- https://git.kernel.org/stable/c/c520943a00ad5015704969ad3304c956bcd49d25
- https://git.kernel.org/stable/c/f5734b1714ca355703e9ea8fb61d04beff1790b9
- https://git.kernel.org/stable/c/8bf902fee5893cfc2f04a698abab47629699ae9a
- https://git.kernel.org/stable/c/b10252c7ae9c9d7c90552f88b544a44ee773af64
- https://git.kernel.org/stable/c/c520943a00ad5015704969ad3304c956bcd49d25
- https://git.kernel.org/stable/c/f5734b1714ca355703e9ea8fb61d04beff1790b9
Modified: 2025-09-24
CVE-2021-47508
In the Linux kernel, the following vulnerability has been resolved: btrfs: free exchange changeset on failures Fstests runs on my VMs have show several kmemleak reports like the following. unreferenced object 0xffff88811ae59080 (size 64): comm "xfs_io", pid 12124, jiffies 4294987392 (age 6.368s) hex dump (first 32 bytes): 00 c0 1c 00 00 00 00 00 ff cf 1c 00 00 00 00 00 ................ 90 97 e5 1a 81 88 ff ff 90 97 e5 1a 81 88 ff ff ................ backtrace: [<00000000ac0176d2>] ulist_add_merge+0x60/0x150 [btrfs] [<0000000076e9f312>] set_state_bits+0x86/0xc0 [btrfs] [<0000000014fe73d6>] set_extent_bit+0x270/0x690 [btrfs] [<000000004f675208>] set_record_extent_bits+0x19/0x20 [btrfs] [<00000000b96137b1>] qgroup_reserve_data+0x274/0x310 [btrfs] [<0000000057e9dcbb>] btrfs_check_data_free_space+0x5c/0xa0 [btrfs] [<0000000019c4511d>] btrfs_delalloc_reserve_space+0x1b/0xa0 [btrfs] [<000000006d37e007>] btrfs_dio_iomap_begin+0x415/0x970 [btrfs] [<00000000fb8a74b8>] iomap_iter+0x161/0x1e0 [<0000000071dff6ff>] __iomap_dio_rw+0x1df/0x700 [<000000002567ba53>] iomap_dio_rw+0x5/0x20 [<0000000072e555f8>] btrfs_file_write_iter+0x290/0x530 [btrfs] [<000000005eb3d845>] new_sync_write+0x106/0x180 [<000000003fb505bf>] vfs_write+0x24d/0x2f0 [<000000009bb57d37>] __x64_sys_pwrite64+0x69/0xa0 [<000000003eba3fdf>] do_syscall_64+0x43/0x90 In case brtfs_qgroup_reserve_data() or btrfs_delalloc_reserve_metadata() fail the allocated extent_changeset will not be freed. So in btrfs_check_data_free_space() and btrfs_delalloc_reserve_space() free the allocated extent_changeset to get rid of the allocated memory. The issue currently only happens in the direct IO write path, but only after 65b3c08606e5 ("btrfs: fix ENOSPC failure when attempting direct IO write into NOCOW range"), and also at defrag_one_locked_target(). Every other place is always calling extent_changeset_free() even if its call to btrfs_delalloc_reserve_space() or btrfs_check_data_free_space() has failed.
Modified: 2025-09-29
CVE-2021-47509
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Limit the period size to 16MB Set the practical limit to the period size (the fragment shift in OSS) instead of a full 31bit; a too large value could lead to the exhaust of memory as we allocate temporary buffers of the period size, too. As of this patch, we set to 16MB limit, which should cover all use cases.
- https://git.kernel.org/stable/c/2e54cf6794bf82a54aaefc78da13819aea9cd28a
- https://git.kernel.org/stable/c/35a3e511032146941085f87dd9fb5b82ea5c00a2
- https://git.kernel.org/stable/c/76f19e4cbb548e28547f8c328aa0bfb3a10222d3
- https://git.kernel.org/stable/c/8839c8c0f77ab8fc0463f4ab8b37fca3f70677c2
- https://git.kernel.org/stable/c/ad45babf7886e7a212ee1d5eda9ef49f696db43c
- https://git.kernel.org/stable/c/b02a41eebcc36d4f07196780f2e165ca2c499257
- https://git.kernel.org/stable/c/be55f306396cd62c6889286a7194fd8b53363aeb
- https://git.kernel.org/stable/c/d1bb703ad050de9095f10b2d3416c32921ac6bcc
- https://git.kernel.org/stable/c/2e54cf6794bf82a54aaefc78da13819aea9cd28a
- https://git.kernel.org/stable/c/35a3e511032146941085f87dd9fb5b82ea5c00a2
- https://git.kernel.org/stable/c/76f19e4cbb548e28547f8c328aa0bfb3a10222d3
- https://git.kernel.org/stable/c/8839c8c0f77ab8fc0463f4ab8b37fca3f70677c2
- https://git.kernel.org/stable/c/ad45babf7886e7a212ee1d5eda9ef49f696db43c
- https://git.kernel.org/stable/c/b02a41eebcc36d4f07196780f2e165ca2c499257
- https://git.kernel.org/stable/c/be55f306396cd62c6889286a7194fd8b53363aeb
- https://git.kernel.org/stable/c/d1bb703ad050de9095f10b2d3416c32921ac6bcc
Modified: 2025-09-29
CVE-2021-47510
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix re-dirty process of tree-log nodes There is a report of a transaction abort of -EAGAIN with the following script. #!/bin/sh for d in sda sdb; do mkfs.btrfs -d single -m single -f /dev/\${d} done mount /dev/sda /mnt/test mount /dev/sdb /mnt/scratch for dir in test scratch; do echo 3 >/proc/sys/vm/drop_caches fio --directory=/mnt/\${dir} --name=fio.\${dir} --rw=read --size=50G --bs=64m \ --numjobs=$(nproc) --time_based --ramp_time=5 --runtime=480 \ --group_reporting |& tee /dev/shm/fio.\${dir} echo 3 >/proc/sys/vm/drop_caches done for d in sda sdb; do umount /dev/\${d} done The stack trace is shown in below. [3310.967991] BTRFS: error (device sda) in btrfs_commit_transaction:2341: errno=-11 unknown (Error while writing out transaction) [3310.968060] BTRFS info (device sda): forced readonly [3310.968064] BTRFS warning (device sda): Skipping commit of aborted transaction. [3310.968065] ------------[ cut here ]------------ [3310.968066] BTRFS: Transaction aborted (error -11) [3310.968074] WARNING: CPU: 14 PID: 1684 at fs/btrfs/transaction.c:1946 btrfs_commit_transaction.cold+0x209/0x2c8 [3310.968131] CPU: 14 PID: 1684 Comm: fio Not tainted 5.14.10-300.fc35.x86_64 #1 [3310.968135] Hardware name: DIAWAY Tartu/Tartu, BIOS V2.01.B10 04/08/2021 [3310.968137] RIP: 0010:btrfs_commit_transaction.cold+0x209/0x2c8 [3310.968144] RSP: 0018:ffffb284ce393e10 EFLAGS: 00010282 [3310.968147] RAX: 0000000000000026 RBX: ffff973f147b0f60 RCX: 0000000000000027 [3310.968149] RDX: ffff974ecf098a08 RSI: 0000000000000001 RDI: ffff974ecf098a00 [3310.968150] RBP: ffff973f147b0f08 R08: 0000000000000000 R09: ffffb284ce393c48 [3310.968151] R10: ffffb284ce393c40 R11: ffffffff84f47468 R12: ffff973f101bfc00 [3310.968153] R13: ffff971f20cf2000 R14: 00000000fffffff5 R15: ffff973f147b0e58 [3310.968154] FS: 00007efe65468740(0000) GS:ffff974ecf080000(0000) knlGS:0000000000000000 [3310.968157] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [3310.968158] CR2: 000055691bcbe260 CR3: 000000105cfa4001 CR4: 0000000000770ee0 [3310.968160] PKRU: 55555554 [3310.968161] Call Trace: [3310.968167] ? dput+0xd4/0x300 [3310.968174] btrfs_sync_file+0x3f1/0x490 [3310.968180] __x64_sys_fsync+0x33/0x60 [3310.968185] do_syscall_64+0x3b/0x90 [3310.968190] entry_SYSCALL_64_after_hwframe+0x44/0xae [3310.968194] RIP: 0033:0x7efe6557329b [3310.968200] RSP: 002b:00007ffe0236ebc0 EFLAGS: 00000293 ORIG_RAX: 000000000000004a [3310.968203] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007efe6557329b [3310.968204] RDX: 0000000000000000 RSI: 00007efe58d77010 RDI: 0000000000000006 [3310.968205] RBP: 0000000004000000 R08: 0000000000000000 R09: 00007efe58d77010 [3310.968207] R10: 0000000016cacc0c R11: 0000000000000293 R12: 00007efe5ce95980 [3310.968208] R13: 0000000000000000 R14: 00007efe6447c790 R15: 0000000c80000000 [3310.968212] ---[ end trace 1a346f4d3c0d96ba ]--- [3310.968214] BTRFS: error (device sda) in cleanup_transaction:1946: errno=-11 unknown The abort occurs because of a write hole while writing out freeing tree nodes of a tree-log tree. For zoned btrfs, we re-dirty a freed tree node to ensure btrfs can write the region and does not leave a hole on write on a zoned device. The current code fails to re-dirty a node when the tree-log tree's depth is greater or equal to 2. That leads to a transaction abort with -EAGAIN. Fix the issue by properly re-dirtying a node on walking up the tree.
Modified: 2025-09-29
CVE-2021-47511
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix negative period/buffer sizes The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers. This patch changes the code to handle with ssize_t and adds the proper error checks appropriately.
- https://git.kernel.org/stable/c/00a860678098fcd9fa8db2b5fb9d2ddf4776d4cc
- https://git.kernel.org/stable/c/02b2b691b77cd7b951fa7b6c9d44d4e472cdc823
- https://git.kernel.org/stable/c/502e1146873d870f87da3b8f93d6bf2de5f38d0c
- https://git.kernel.org/stable/c/8af815ab052eaf74addbbfb556d63ce2137c0e1b
- https://git.kernel.org/stable/c/9d2479c960875ca1239bcb899f386970c13d9cfe
- https://git.kernel.org/stable/c/be8869d388593e57223ad39297c8e54be632f2f2
- https://git.kernel.org/stable/c/f12c8a7515f641885677960af450082569a87243
- https://git.kernel.org/stable/c/f96c0959c1ee92adc911c10d6ec209af50105049
- https://git.kernel.org/stable/c/00a860678098fcd9fa8db2b5fb9d2ddf4776d4cc
- https://git.kernel.org/stable/c/02b2b691b77cd7b951fa7b6c9d44d4e472cdc823
- https://git.kernel.org/stable/c/502e1146873d870f87da3b8f93d6bf2de5f38d0c
- https://git.kernel.org/stable/c/8af815ab052eaf74addbbfb556d63ce2137c0e1b
- https://git.kernel.org/stable/c/9d2479c960875ca1239bcb899f386970c13d9cfe
- https://git.kernel.org/stable/c/be8869d388593e57223ad39297c8e54be632f2f2
- https://git.kernel.org/stable/c/f12c8a7515f641885677960af450082569a87243
- https://git.kernel.org/stable/c/f96c0959c1ee92adc911c10d6ec209af50105049
Modified: 2025-01-06
CVE-2021-47512
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq_pie: prevent dismantle issue
For some reason, fq_pie_destroy() did not copy
working code from pie_destroy() and other qdiscs,
thus causing elusive bug.
Before calling del_timer_sync(&q->adapt_timer),
we need to ensure timer will not rearm itself.
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579
(t=10501 jiffies g=13085 q=3989)
NMI backtrace for cpu 0
CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
- https://git.kernel.org/stable/c/2a51edaf5cc563574878b93d7ef3d5955dda7030
- https://git.kernel.org/stable/c/61c2402665f1e10c5742033fce18392e369931d7
- https://git.kernel.org/stable/c/d86216dfda7c98375f809e26a30bfdaaba21d46e
- https://git.kernel.org/stable/c/2a51edaf5cc563574878b93d7ef3d5955dda7030
- https://git.kernel.org/stable/c/61c2402665f1e10c5742033fce18392e369931d7
- https://git.kernel.org/stable/c/d86216dfda7c98375f809e26a30bfdaaba21d46e
Modified: 2024-11-21
CVE-2021-47513
In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: Fix memory leak in felix_setup_mmio_filtering Avoid a memory leak if there is not a CPU port defined. Addresses-Coverity-ID: 1492897 ("Resource leak") Addresses-Coverity-ID: 1492899 ("Resource leak")
Modified: 2025-01-06
CVE-2021-47514
In the Linux kernel, the following vulnerability has been resolved: devlink: fix netns refcount leak in devlink_nl_cmd_reload() While preparing my patch series adding netns refcount tracking, I spotted bugs in devlink_nl_cmd_reload() Some error paths forgot to release a refcount on a netns. To fix this, we can reduce the scope of get_net()/put_net() section around the call to devlink_reload().
- https://git.kernel.org/stable/c/4b7e90672af8e0c78205db006f1b0a20ebd07f5f
- https://git.kernel.org/stable/c/4dbb0dad8e63fcd0b5a117c2861d2abe7ff5f186
- https://git.kernel.org/stable/c/fe30b70ca84da9c4aca85c03ad86e7a9b89c5ded
- https://git.kernel.org/stable/c/4b7e90672af8e0c78205db006f1b0a20ebd07f5f
- https://git.kernel.org/stable/c/4dbb0dad8e63fcd0b5a117c2861d2abe7ff5f186
- https://git.kernel.org/stable/c/fe30b70ca84da9c4aca85c03ad86e7a9b89c5ded
Modified: 2025-09-24
CVE-2021-47515
In the Linux kernel, the following vulnerability has been resolved: seg6: fix the iif in the IPv6 socket control block When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif; If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29). Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero). As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied. To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again.
- https://git.kernel.org/stable/c/6431e71093f3da586a00c6d931481ffb0dc2db0e
- https://git.kernel.org/stable/c/666521b3852d2b2f52d570f9122b1e4b50d96831
- https://git.kernel.org/stable/c/98adb2bbfa407c9290bda299d4c6f7a1c4ebd5e1
- https://git.kernel.org/stable/c/ae68d93354e5bf5191ee673982251864ea24dd5c
- https://git.kernel.org/stable/c/b16d412e5f79734033df04e97d7ea2f50a8e9fe3
- https://git.kernel.org/stable/c/ef8804e47c0a44ae106ead1740408af5ea6c6ee9
- https://git.kernel.org/stable/c/6431e71093f3da586a00c6d931481ffb0dc2db0e
- https://git.kernel.org/stable/c/666521b3852d2b2f52d570f9122b1e4b50d96831
- https://git.kernel.org/stable/c/98adb2bbfa407c9290bda299d4c6f7a1c4ebd5e1
- https://git.kernel.org/stable/c/ae68d93354e5bf5191ee673982251864ea24dd5c
- https://git.kernel.org/stable/c/b16d412e5f79734033df04e97d7ea2f50a8e9fe3
- https://git.kernel.org/stable/c/ef8804e47c0a44ae106ead1740408af5ea6c6ee9
Modified: 2024-11-21
CVE-2021-47516
In the Linux kernel, the following vulnerability has been resolved: nfp: Fix memory leak in nfp_cpp_area_cache_add() In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak. We can fix it by freeing the CPP area when the cache is allocated failed (#2). 792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache *cache; 795 struct nfp_cpp_area *area; 800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes 802 if (!area) 803 return -ENOMEM; 805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free 817 return 0; 818 }
- https://git.kernel.org/stable/c/2e0e072e62fdaf7816220af08e05c020f0fcb77a
- https://git.kernel.org/stable/c/3e93abcdcec0436fbf0b6a88ae806902426895a2
- https://git.kernel.org/stable/c/484069b5de9d223cc1c64c6f80389a99cfef51f1
- https://git.kernel.org/stable/c/c56c96303e9289cc34716b1179597b6f470833de
- https://git.kernel.org/stable/c/eb51f639ef3fd5498b7def290ed8681b6aadd9a7
- https://git.kernel.org/stable/c/f707820c09239d6f67699d9b2ff57863cc7905b0
- https://git.kernel.org/stable/c/2e0e072e62fdaf7816220af08e05c020f0fcb77a
- https://git.kernel.org/stable/c/3e93abcdcec0436fbf0b6a88ae806902426895a2
- https://git.kernel.org/stable/c/484069b5de9d223cc1c64c6f80389a99cfef51f1
- https://git.kernel.org/stable/c/c56c96303e9289cc34716b1179597b6f470833de
- https://git.kernel.org/stable/c/eb51f639ef3fd5498b7def290ed8681b6aadd9a7
- https://git.kernel.org/stable/c/f707820c09239d6f67699d9b2ff57863cc7905b0
Modified: 2025-03-01
CVE-2021-47517
In the Linux kernel, the following vulnerability has been resolved: ethtool: do not perform operations on net devices being unregistered There is a short period between a net device starts to be unregistered and when it is actually gone. In that time frame ethtool operations could still be performed, which might end up in unwanted or undefined behaviours[1]. Do not allow ethtool operations after a net device starts its unregistration. This patch targets the netlink part as the ioctl one isn't affected: the reference to the net device is taken and the operation is executed within an rtnl lock section and the net device won't be found after unregister. [1] For example adding Tx queues after unregister ends up in NULL pointer exceptions and UaFs, such as: BUG: KASAN: use-after-free in kobject_get+0x14/0x90 Read of size 1 at addr ffff88801961248c by task ethtool/755 CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014 Call Trace: dump_stack_lvl+0x57/0x72 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b kobject_get+0x14/0x90 kobject_add_internal+0x3d1/0x450 kobject_init_and_add+0xba/0xf0 netdev_queue_update_kobjects+0xcf/0x200 netif_set_real_num_tx_queues+0xb4/0x310 veth_set_channels+0x1c3/0x550 ethnl_set_channels+0x524/0x610
- https://git.kernel.org/stable/c/7c26da3be1e9843a15b5318f90db8a564479d2ac
- https://git.kernel.org/stable/c/cfd719f04267108f5f5bf802b9d7de69e99a99f9
- https://git.kernel.org/stable/c/dde91ccfa25fd58f64c397d91b81a4b393100ffa
- https://git.kernel.org/stable/c/7c26da3be1e9843a15b5318f90db8a564479d2ac
- https://git.kernel.org/stable/c/cfd719f04267108f5f5bf802b9d7de69e99a99f9
- https://git.kernel.org/stable/c/dde91ccfa25fd58f64c397d91b81a4b393100ffa
Modified: 2024-11-21
CVE-2021-47518
In the Linux kernel, the following vulnerability has been resolved: nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done The done() netlink callback nfc_genl_dump_ses_done() should check if received argument is non-NULL, because its allocation could fail earlier in dumpit() (nfc_genl_dump_ses()).
- https://git.kernel.org/stable/c/3b861a40325eac9c4c13b6c53874ad90617e944d
- https://git.kernel.org/stable/c/48fcd08fdbe05e35b650a252ec2a2d96057a1c7a
- https://git.kernel.org/stable/c/4cd8371a234d051f9c9557fcbb1f8c523b1c0d10
- https://git.kernel.org/stable/c/69bb79a8f5bb9f436b6f1434ca9742591b7bbe18
- https://git.kernel.org/stable/c/811a7576747760bcaf60502f096d1e6e91d566fa
- https://git.kernel.org/stable/c/83ea620a1be840bf05089a5061fb8323ca42f38c
- https://git.kernel.org/stable/c/87cdb8789c38e44ae5454aafe277997c950d00ed
- https://git.kernel.org/stable/c/fae9705d281091254d4a81fa2da9d22346097dca
- https://git.kernel.org/stable/c/3b861a40325eac9c4c13b6c53874ad90617e944d
- https://git.kernel.org/stable/c/48fcd08fdbe05e35b650a252ec2a2d96057a1c7a
- https://git.kernel.org/stable/c/4cd8371a234d051f9c9557fcbb1f8c523b1c0d10
- https://git.kernel.org/stable/c/69bb79a8f5bb9f436b6f1434ca9742591b7bbe18
- https://git.kernel.org/stable/c/811a7576747760bcaf60502f096d1e6e91d566fa
- https://git.kernel.org/stable/c/83ea620a1be840bf05089a5061fb8323ca42f38c
- https://git.kernel.org/stable/c/87cdb8789c38e44ae5454aafe277997c950d00ed
- https://git.kernel.org/stable/c/fae9705d281091254d4a81fa2da9d22346097dca
Modified: 2024-11-21
CVE-2021-47519
In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_read_fifo: fix memory leak in error branch In m_can_read_fifo(), if the second call to m_can_fifo_read() fails, the function jump to the out_fail label and returns without calling m_can_receive_skb(). This means that the skb previously allocated by alloc_can_skb() is not freed. In other terms, this is a memory leak. This patch adds a goto label to destroy the skb if an error occurs. Issue was found with GCC -fanalyzer, please follow the link below for details.
Modified: 2024-11-21
CVE-2021-47520
In the Linux kernel, the following vulnerability has been resolved: can: pch_can: pch_can_rx_normal: fix use after free After calling netif_receive_skb(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is dereferenced just after the call netif_receive_skb(skb). Reordering the lines solves the issue.
- https://git.kernel.org/stable/c/3a3c46e2eff0577454860a203be1a8295f4acb76
- https://git.kernel.org/stable/c/3e193ef4e0a3f5bf92ede83ef214cb09d01b00aa
- https://git.kernel.org/stable/c/6c73fc931658d8cbc8a1714b326cb31eb71d16a7
- https://git.kernel.org/stable/c/703dde112021c93d6e89443c070e7dbd4dea612e
- https://git.kernel.org/stable/c/94cddf1e9227a171b27292509d59691819c458db
- https://git.kernel.org/stable/c/abb4eff3dcd2e583060082a18a8dbf31f02689d4
- https://git.kernel.org/stable/c/affbad02bf80380a7403885b9fe4a1587d1bb4f3
- https://git.kernel.org/stable/c/bafe343a885c70dddf358379cf0b2a1c07355d8d
- https://git.kernel.org/stable/c/3a3c46e2eff0577454860a203be1a8295f4acb76
- https://git.kernel.org/stable/c/3e193ef4e0a3f5bf92ede83ef214cb09d01b00aa
- https://git.kernel.org/stable/c/6c73fc931658d8cbc8a1714b326cb31eb71d16a7
- https://git.kernel.org/stable/c/703dde112021c93d6e89443c070e7dbd4dea612e
- https://git.kernel.org/stable/c/94cddf1e9227a171b27292509d59691819c458db
- https://git.kernel.org/stable/c/abb4eff3dcd2e583060082a18a8dbf31f02689d4
- https://git.kernel.org/stable/c/affbad02bf80380a7403885b9fe4a1587d1bb4f3
- https://git.kernel.org/stable/c/bafe343a885c70dddf358379cf0b2a1c07355d8d
Modified: 2024-11-21
CVE-2021-47521
In the Linux kernel, the following vulnerability has been resolved: can: sja1000: fix use after free in ems_pcmcia_add_card() If the last channel is not available then "dev" is freed. Fortunately, we can just use "pdev->irq" instead. Also we should check if at least one channel was set up.
- https://git.kernel.org/stable/c/1a295fea90e1acbe80c6d4940f5ff856edcd6bec
- https://git.kernel.org/stable/c/1dd5b819f7e406dc15bbc7670596ff25261aaa2a
- https://git.kernel.org/stable/c/3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45
- https://git.kernel.org/stable/c/474f9a8534f5f89841240a7e978bafd6e1e039ce
- https://git.kernel.org/stable/c/923f4dc5df679f678e121c20bf2fd70f7bf3e288
- https://git.kernel.org/stable/c/c8718026ba287168ff9ad0ccc4f9a413062cba36
- https://git.kernel.org/stable/c/cbd86110546f7f730a1f5d7de56c944a336c15c4
- https://git.kernel.org/stable/c/ccf070183e4655824936c0f96c4a2bcca93419aa
- https://git.kernel.org/stable/c/1a295fea90e1acbe80c6d4940f5ff856edcd6bec
- https://git.kernel.org/stable/c/1dd5b819f7e406dc15bbc7670596ff25261aaa2a
- https://git.kernel.org/stable/c/3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45
- https://git.kernel.org/stable/c/474f9a8534f5f89841240a7e978bafd6e1e039ce
- https://git.kernel.org/stable/c/923f4dc5df679f678e121c20bf2fd70f7bf3e288
- https://git.kernel.org/stable/c/c8718026ba287168ff9ad0ccc4f9a413062cba36
- https://git.kernel.org/stable/c/cbd86110546f7f730a1f5d7de56c944a336c15c4
- https://git.kernel.org/stable/c/ccf070183e4655824936c0f96c4a2bcca93419aa
Modified: 2024-11-21
CVE-2021-47522
In the Linux kernel, the following vulnerability has been resolved: HID: bigbenff: prevent null pointer dereference When emulating the device through uhid, there is a chance we don't have output reports and so report_field is null.
- https://git.kernel.org/stable/c/58f15f5ae7786c824868f3a7e093859b74669ce7
- https://git.kernel.org/stable/c/6272b17001e6fdcf7b4a16206287010a1523fa6e
- https://git.kernel.org/stable/c/8e0ceff632f48175ec7fb4706129c55ca8a7c7bd
- https://git.kernel.org/stable/c/918aa1ef104d286d16b9e7ef139a463ac7a296f0
- https://git.kernel.org/stable/c/58f15f5ae7786c824868f3a7e093859b74669ce7
- https://git.kernel.org/stable/c/6272b17001e6fdcf7b4a16206287010a1523fa6e
- https://git.kernel.org/stable/c/8e0ceff632f48175ec7fb4706129c55ca8a7c7bd
- https://git.kernel.org/stable/c/918aa1ef104d286d16b9e7ef139a463ac7a296f0
Modified: 2025-09-24
CVE-2021-47523
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddr This buffer is currently allocated in hfi1_init(): if (reinit) ret = init_after_reset(dd); else ret = loadtime_init(dd); if (ret) goto done; /* allocate dummy tail memory for all receive contexts */ dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64), &dd->rcvhdrtail_dummy_dma, GFP_KERNEL); if (!dd->rcvhdrtail_dummy_kvaddr) { dd_dev_err(dd, "cannot allocate dummy tail memory\n"); ret = -ENOMEM; goto done; } The reinit triggered path will overwrite the old allocation and leak it. Fix by moving the allocation to hfi1_alloc_devdata() and the deallocation to hfi1_free_devdata().
- https://git.kernel.org/stable/c/2c08271f4ed0e24633b3f81ceff61052b9d45efc
- https://git.kernel.org/stable/c/60a8b5a1611b4a26de4839ab9c1fc2a9cf3e17c1
- https://git.kernel.org/stable/c/834d0fb978643eaf09da425de197cc16a7c2761b
- https://git.kernel.org/stable/c/2c08271f4ed0e24633b3f81ceff61052b9d45efc
- https://git.kernel.org/stable/c/60a8b5a1611b4a26de4839ab9c1fc2a9cf3e17c1
- https://git.kernel.org/stable/c/834d0fb978643eaf09da425de197cc16a7c2761b
Modified: 2025-09-24
CVE-2021-47524
In the Linux kernel, the following vulnerability has been resolved: serial: liteuart: fix minor-number leak on probe errors Make sure to release the allocated minor number before returning on probe errors.
Modified: 2024-11-21
CVE-2021-47525
In the Linux kernel, the following vulnerability has been resolved: serial: liteuart: fix use-after-free and memleak on unbind Deregister the port when unbinding the driver to prevent it from being used after releasing the driver data and leaking memory allocated by serial core.
Modified: 2024-11-21
CVE-2021-47526
In the Linux kernel, the following vulnerability has been resolved: serial: liteuart: Fix NULL pointer dereference in ->remove() drvdata has to be set in _probe() - otherwise platform_get_drvdata() causes null pointer dereference BUG in _remove().
Modified: 2025-09-24
CVE-2021-47527
In the Linux kernel, the following vulnerability has been resolved: serial: core: fix transmit-buffer reset and memleak Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")).
- https://git.kernel.org/stable/c/00de977f9e0aa9760d9a79d1e41ff780f74e3424
- https://git.kernel.org/stable/c/011f6c92b5bf6e1fbfdedc8b5232f64c1c493206
- https://git.kernel.org/stable/c/1179b168fa3f3a6aae3bd140000455a0e58457db
- https://git.kernel.org/stable/c/64e491c1634b73d3bddc081d08620bdc92ab2c12
- https://git.kernel.org/stable/c/c5da8aa441053958594f94254592bb41264bdfbf
- https://git.kernel.org/stable/c/e1722acf4f0d4d67b60f57e08ce16f8b66cd4b8f
- https://git.kernel.org/stable/c/e74d9663fd57640fc3394abb5c76fa95b9cc2f2e
- https://git.kernel.org/stable/c/00de977f9e0aa9760d9a79d1e41ff780f74e3424
- https://git.kernel.org/stable/c/011f6c92b5bf6e1fbfdedc8b5232f64c1c493206
- https://git.kernel.org/stable/c/1179b168fa3f3a6aae3bd140000455a0e58457db
- https://git.kernel.org/stable/c/64e491c1634b73d3bddc081d08620bdc92ab2c12
- https://git.kernel.org/stable/c/c5da8aa441053958594f94254592bb41264bdfbf
- https://git.kernel.org/stable/c/e1722acf4f0d4d67b60f57e08ce16f8b66cd4b8f
- https://git.kernel.org/stable/c/e74d9663fd57640fc3394abb5c76fa95b9cc2f2e
Modified: 2024-11-21
CVE-2021-47528
In the Linux kernel, the following vulnerability has been resolved: usb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init() In cdnsp_endpoint_init(), cdnsp_ring_alloc() is assigned to pep->ring and there is a dereference of it in cdnsp_endpoint_init(), which could lead to a NULL pointer dereference on failure of cdnsp_ring_alloc(). Fix this bug by adding a check of pep->ring. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_USB_CDNSP_GADGET=y show no new warnings, and our static analyzer no longer warns about this code.
Modified: 2024-11-21
CVE-2021-47529
In the Linux kernel, the following vulnerability has been resolved: iwlwifi: Fix memory leaks in error handling path Should an error occur (invalid TLV len or memory allocation failure), the memory already allocated in 'reduce_power_data' should be freed before returning, otherwise it is leaking.
Modified: 2025-09-29
CVE-2021-47530
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix wait_fence submitqueue leak We weren't dropping the submitqueue reference in all paths. In particular, when the fence has already been signalled. Split out a helper to simplify handling this in the various different return paths.
Modified: 2025-09-29
CVE-2021-47531
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object function") we switched to a new/cleaner method of doing things. That's good, but we missed a little bit. Before that commit, we used to _first_ run through the drm_gem_mmap_obj() case where `obj->funcs->mmap()` was NULL. That meant that we ran: vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); ...and _then_ we modified those mappings with our own. Now that `obj->funcs->mmap()` is no longer NULL we don't run the default code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP was important because we're now getting crashes on Chromebooks that use ARC++ while logging out. Specifically a crash that looks like this (this is on a 5.10 kernel w/ relevant backports but also seen on a 5.15 kernel): Unable to handle kernel paging request at virtual address ffffffc008000000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008293d000 [ffffffc008000000] pgd=00000001002b3003, p4d=00000001002b3003, pud=00000001002b3003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP [...] CPU: 7 PID: 15734 Comm: crash_dump64 Tainted: G W 5.10.67 #1 [...] Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT) pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) pc : __arch_copy_to_user+0xc0/0x30c lr : copyout+0xac/0x14c [...] Call trace: __arch_copy_to_user+0xc0/0x30c copy_page_to_iter+0x1a0/0x294 process_vm_rw_core+0x240/0x408 process_vm_rw+0x110/0x16c __arm64_sys_process_vm_readv+0x30/0x3c el0_svc_common+0xf8/0x250 do_el0_svc+0x30/0x80 el0_svc+0x10/0x1c el0_sync_handler+0x78/0x108 el0_sync+0x184/0x1c0 Code: f8408423 f80008c3 910020c6 36100082 (b8404423) Let's add the two flags back in. While we're at it, the fact that we aren't running the default means that we _don't_ need to clear out VM_PFNMAP, so remove that and save an instruction. NOTE: it was confirmed that VM_IO was the important flag to fix the problem I was seeing, but adding back VM_DONTDUMP seems like a sane thing to do so I'm doing that too.
Modified: 2025-09-18
CVE-2021-47532
In the Linux kernel, the following vulnerability has been resolved: drm/msm/devfreq: Fix OPP refcnt leak
Modified: 2025-09-18
CVE-2021-47533
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: kms: Clear the HVS FIFO commit pointer once done Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a wait on the previous commit done on a given HVS FIFO. However, we never cleared that pointer once done. Since drm_crtc_commit_put can free the drm_crtc_commit structure directly if we were the last user, this means that it can lead to a use-after free if we were to duplicate the state, and that stale pointer would even be copied to the new state. Set the pointer to NULL once we're done with the wait so that we don't carry over a pointer to a free'd structure.
Modified: 2025-04-01
CVE-2021-47534
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: kms: Add missing drm_crtc_commit_put Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a global state for the HVS, with each FIFO storing the current CRTC commit so that we can properly synchronize commits. However, the refcounting was off and we thus ended up leaking the drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to prevent the leakage.
Modified: 2025-04-01
CVE-2021-47535
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Allocate enough space for GMU registers In commit 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for A650") we changed a6xx_get_gmu_registers() to read 3 sets of registers. Unfortunately, we didn't change the memory allocation for the array. That leads to a KASAN warning (this was on the chromeos-5.4 kernel, which has the problematic commit backported to it): BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430 Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209 CPU: 5 PID: 209 Comm: A618-worker Tainted: G W 5.4.156-lockdep #22 Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT) Call trace: dump_backtrace+0x0/0x248 show_stack+0x20/0x2c dump_stack+0x128/0x1ec print_address_description+0x88/0x4a0 __kasan_report+0xfc/0x120 kasan_report+0x10/0x18 __asan_report_store8_noabort+0x1c/0x24 _a6xx_get_gmu_registers+0x144/0x430 a6xx_gpu_state_get+0x330/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18 Allocated by task 209: __kasan_kmalloc+0xfc/0x1c4 kasan_kmalloc+0xc/0x14 kmem_cache_alloc_trace+0x1f0/0x2a0 a6xx_gpu_state_get+0x164/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18
- https://git.kernel.org/stable/c/83e54fcf0b14ca2d869dd37abe1bb6542805f538
- https://git.kernel.org/stable/c/b4d25abf9720b69a03465b09d0d62d1998ed6708
- https://git.kernel.org/stable/c/d646856a600e8635ba498f20b194219b158626e8
- https://git.kernel.org/stable/c/83e54fcf0b14ca2d869dd37abe1bb6542805f538
- https://git.kernel.org/stable/c/b4d25abf9720b69a03465b09d0d62d1998ed6708
- https://git.kernel.org/stable/c/d646856a600e8635ba498f20b194219b158626e8
Modified: 2025-09-18
CVE-2021-47536
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix wrong list_del in smc_lgr_cleanup_early smc_lgr_cleanup_early() meant to delete the link group from the link group list, but it deleted the list head by mistake. This may cause memory corruption since we didn't remove the real link group from the list and later memseted the link group structure. We got a list corruption panic when testing: [ 231.277259] list_del corruption. prev->next should be ffff8881398a8000, but was 0000000000000000 [ 231.278222] ------------[ cut here ]------------ [ 231.278726] kernel BUG at lib/list_debug.c:53! [ 231.279326] invalid opcode: 0000 [#1] SMP NOPTI [ 231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435 [ 231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 [ 231.281248] Workqueue: events smc_link_down_work [ 231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90 [ 231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <0f> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc [ 231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292 [ 231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000 [ 231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040 [ 231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001 [ 231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001 [ 231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003 [ 231.288337] FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 231.289160] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0 [ 231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 231.291940] Call Trace: [ 231.292211] smc_lgr_terminate_sched+0x53/0xa0 [ 231.292677] smc_switch_conns+0x75/0x6b0 [ 231.293085] ? update_load_avg+0x1a6/0x590 [ 231.293517] ? ttwu_do_wakeup+0x17/0x150 [ 231.293907] ? update_load_avg+0x1a6/0x590 [ 231.294317] ? newidle_balance+0xca/0x3d0 [ 231.294716] smcr_link_down+0x50/0x1a0 [ 231.295090] ? __wake_up_common_lock+0x77/0x90 [ 231.295534] smc_link_down_work+0x46/0x60 [ 231.295933] process_one_work+0x18b/0x350
- https://git.kernel.org/stable/c/77731fede297a23d26f2d169b4269466b2c82529
- https://git.kernel.org/stable/c/789b6cc2a5f9123b9c549b886fdc47c865cfe0ba
- https://git.kernel.org/stable/c/95518fe354d712dca6f431cf2a11b8f63bc9a66c
- https://git.kernel.org/stable/c/77731fede297a23d26f2d169b4269466b2c82529
- https://git.kernel.org/stable/c/789b6cc2a5f9123b9c549b886fdc47c865cfe0ba
- https://git.kernel.org/stable/c/95518fe354d712dca6f431cf2a11b8f63bc9a66c
Modified: 2024-11-21
CVE-2021-47537
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix a memleak bug in rvu_mbox_init() In rvu_mbox_init(), mbox_regions is not freed or passed out under the switch-default region, which could lead to a memory leak. Fix this bug by changing 'return err' to 'goto free_regions'. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_OCTEONTX2_AF=y show no new warnings, and our static analyzer no longer warns about this code.
Modified: 2025-09-18
CVE-2021-47538
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer() Need to call rxrpc_put_local() for peer candidate before kfree() as it holds a ref to rxrpc_local. [DH: v2: Changed to abstract the peer freeing code out into a function]
- https://git.kernel.org/stable/c/3e70e3a72d80b16094faccbe438cd53761c3503a
- https://git.kernel.org/stable/c/60f0b9c42cb80833a03ca57c1c8b078d716e71d1
- https://git.kernel.org/stable/c/913c24af2d13a3fd304462916ee98e298d56bdce
- https://git.kernel.org/stable/c/9469273e616ca8f1b6e3773c5019f21b4c8d828c
- https://git.kernel.org/stable/c/beacff50edbd6c9659a6f15fc7f6126909fade29
- https://git.kernel.org/stable/c/3e70e3a72d80b16094faccbe438cd53761c3503a
- https://git.kernel.org/stable/c/60f0b9c42cb80833a03ca57c1c8b078d716e71d1
- https://git.kernel.org/stable/c/913c24af2d13a3fd304462916ee98e298d56bdce
- https://git.kernel.org/stable/c/9469273e616ca8f1b6e3773c5019f21b4c8d828c
- https://git.kernel.org/stable/c/beacff50edbd6c9659a6f15fc7f6126909fade29
Modified: 2025-09-18
CVE-2021-47539
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxrpc_peer leak in rxrpc_look_up_bundle() Need to call rxrpc_put_peer() for bundle candidate before kfree() as it holds a ref to rxrpc_peer. [DH: v2: Changed to abstract out the bundle freeing code into a function]
- https://git.kernel.org/stable/c/35b40f724c4ef0f683d94dab3af9ab38261d782b
- https://git.kernel.org/stable/c/bc97458620e38961af9505cc060ad4cf5c9e4af7
- https://git.kernel.org/stable/c/ca77fba821351190777b236ce749d7c4d353102e
- https://git.kernel.org/stable/c/35b40f724c4ef0f683d94dab3af9ab38261d782b
- https://git.kernel.org/stable/c/bc97458620e38961af9505cc060ad4cf5c9e4af7
- https://git.kernel.org/stable/c/ca77fba821351190777b236ce749d7c4d353102e
Modified: 2024-11-21
CVE-2021-47540
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix NULL pointer dereference in mt7915_get_phy_mode Fix the following NULL pointer dereference in mt7915_get_phy_mode routine adding an ibss interface to the mt7915 driver. [ 101.137097] wlan0: Trigger new scan to find an IBSS to join [ 102.827039] wlan0: Creating new IBSS network, BSSID 26:a4:50:1a:6e:69 [ 103.064756] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 103.073670] Mem abort info: [ 103.076520] ESR = 0x96000005 [ 103.079614] EC = 0x25: DABT (current EL), IL = 32 bits [ 103.084934] SET = 0, FnV = 0 [ 103.088042] EA = 0, S1PTW = 0 [ 103.091215] Data abort info: [ 103.094104] ISV = 0, ISS = 0x00000005 [ 103.098041] CM = 0, WnR = 0 [ 103.101044] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000460b1000 [ 103.107565] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 103.116590] Internal error: Oops: 96000005 [#1] SMP [ 103.189066] CPU: 1 PID: 333 Comm: kworker/u4:3 Not tainted 5.10.75 #0 [ 103.195498] Hardware name: MediaTek MT7622 RFB1 board (DT) [ 103.201124] Workqueue: phy0 ieee80211_iface_work [mac80211] [ 103.206695] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--) [ 103.212705] pc : mt7915_get_phy_mode+0x68/0x120 [mt7915e] [ 103.218103] lr : mt7915_mcu_add_bss_info+0x11c/0x760 [mt7915e] [ 103.223927] sp : ffffffc011cdb9e0 [ 103.227235] x29: ffffffc011cdb9e0 x28: ffffff8006563098 [ 103.232545] x27: ffffff8005f4da22 x26: ffffff800685ac40 [ 103.237855] x25: 0000000000000001 x24: 000000000000011f [ 103.243165] x23: ffffff8005f4e260 x22: ffffff8006567918 [ 103.248475] x21: ffffff8005f4df80 x20: ffffff800685ac58 [ 103.253785] x19: ffffff8006744400 x18: 0000000000000000 [ 103.259094] x17: 0000000000000000 x16: 0000000000000001 [ 103.264403] x15: 000899c3a2d9d2e4 x14: 000899bdc3c3a1c8 [ 103.269713] x13: 0000000000000000 x12: 0000000000000000 [ 103.275024] x11: ffffffc010e30c20 x10: 0000000000000000 [ 103.280333] x9 : 0000000000000050 x8 : ffffff8006567d88 [ 103.285642] x7 : ffffff8006563b5c x6 : ffffff8006563b44 [ 103.290952] x5 : 0000000000000002 x4 : 0000000000000001 [ 103.296262] x3 : 0000000000000001 x2 : 0000000000000001 [ 103.301572] x1 : 0000000000000000 x0 : 0000000000000011 [ 103.306882] Call trace: [ 103.309328] mt7915_get_phy_mode+0x68/0x120 [mt7915e] [ 103.314378] mt7915_bss_info_changed+0x198/0x200 [mt7915e] [ 103.319941] ieee80211_bss_info_change_notify+0x128/0x290 [mac80211] [ 103.326360] __ieee80211_sta_join_ibss+0x308/0x6c4 [mac80211] [ 103.332171] ieee80211_sta_create_ibss+0x8c/0x10c [mac80211] [ 103.337895] ieee80211_ibss_work+0x3dc/0x614 [mac80211] [ 103.343185] ieee80211_iface_work+0x388/0x3f0 [mac80211] [ 103.348495] process_one_work+0x288/0x690 [ 103.352499] worker_thread+0x70/0x464 [ 103.356157] kthread+0x144/0x150 [ 103.359380] ret_from_fork+0x10/0x18 [ 103.362952] Code: 394008c3 52800220 394000e4 7100007f (39400023)
- https://git.kernel.org/stable/c/14b03b8cebdf18ff13c39d58501b625411314de2
- https://git.kernel.org/stable/c/6e53d6d26920d5221d3f4d4f5ffdd629ea69aa5c
- https://git.kernel.org/stable/c/932b338f4e5c4cb0c2ed640da3bced1e63620198
- https://git.kernel.org/stable/c/14b03b8cebdf18ff13c39d58501b625411314de2
- https://git.kernel.org/stable/c/6e53d6d26920d5221d3f4d4f5ffdd629ea69aa5c
- https://git.kernel.org/stable/c/932b338f4e5c4cb0c2ed640da3bced1e63620198
Modified: 2024-11-21
CVE-2021-47541
In the Linux kernel, the following vulnerability has been resolved: net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources() In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and tmp->tx_cq will be freed on the error path of mlx4_en_copy_priv(). After that mlx4_en_alloc_resources() is called and there is a dereference of &tmp->tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to a use after free problem on failure of mlx4_en_copy_priv(). Fix this bug by adding a check of mlx4_en_copy_priv() This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_MLX4_EN=m show no new warnings, and our static analyzer no longer warns about this code.
- https://git.kernel.org/stable/c/676dc7d9b15bf8733233a2db1ec3f9091ab34275
- https://git.kernel.org/stable/c/75917372eef0dbfb290ae45474314d35f97aea18
- https://git.kernel.org/stable/c/addad7643142f500080417dd7272f49b7a185570
- https://git.kernel.org/stable/c/be12572c5ddc8ad7453bada4eec8fa46967dc757
- https://git.kernel.org/stable/c/e461a9816a1ac5b4aeb61621b817225b61e46a68
- https://git.kernel.org/stable/c/f1d43efa59f1edd3e7eca0e94559b4c6b1cd4e2b
- https://git.kernel.org/stable/c/676dc7d9b15bf8733233a2db1ec3f9091ab34275
- https://git.kernel.org/stable/c/75917372eef0dbfb290ae45474314d35f97aea18
- https://git.kernel.org/stable/c/addad7643142f500080417dd7272f49b7a185570
- https://git.kernel.org/stable/c/be12572c5ddc8ad7453bada4eec8fa46967dc757
- https://git.kernel.org/stable/c/e461a9816a1ac5b4aeb61621b817225b61e46a68
- https://git.kernel.org/stable/c/f1d43efa59f1edd3e7eca0e94559b4c6b1cd4e2b
Modified: 2024-11-21
CVE-2021-47542
In the Linux kernel, the following vulnerability has been resolved: net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings() In qlcnic_83xx_add_rings(), the indirect function of ahw->hw_ops->alloc_mbx_args will be called to allocate memory for cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(), which could lead to a NULL pointer dereference on failure of the indirect function like qlcnic_83xx_alloc_mbx_args(). Fix this bug by adding a check of alloc_mbx_args(), this patch imitates the logic of mbx_cmd()'s failure handling. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_QLCNIC=m show no new warnings, and our static analyzer no longer warns about this code.
- https://git.kernel.org/stable/c/15fa12c119f869173f9b710cbe6a4a14071d2105
- https://git.kernel.org/stable/c/3a061d54e260b701b538873b43e399d9b8b83e03
- https://git.kernel.org/stable/c/550658a2d61e4eaf522c8ebc7fad76dc376bfb45
- https://git.kernel.org/stable/c/57af54a56024435d83e44c78449513b414eb6edf
- https://git.kernel.org/stable/c/b4f217d6fcc00c3fdc0921a7691f30be7490b073
- https://git.kernel.org/stable/c/bbeb0325a7460ebf1e03f5e0bfc5c652fba9519f
- https://git.kernel.org/stable/c/c5ef33c1489b2cd74368057fa00b5d2183bb5853
- https://git.kernel.org/stable/c/e2dabc4f7e7b60299c20a36d6a7b24ed9bf8e572
- https://git.kernel.org/stable/c/15fa12c119f869173f9b710cbe6a4a14071d2105
- https://git.kernel.org/stable/c/3a061d54e260b701b538873b43e399d9b8b83e03
- https://git.kernel.org/stable/c/550658a2d61e4eaf522c8ebc7fad76dc376bfb45
- https://git.kernel.org/stable/c/57af54a56024435d83e44c78449513b414eb6edf
- https://git.kernel.org/stable/c/b4f217d6fcc00c3fdc0921a7691f30be7490b073
- https://git.kernel.org/stable/c/bbeb0325a7460ebf1e03f5e0bfc5c652fba9519f
- https://git.kernel.org/stable/c/c5ef33c1489b2cd74368057fa00b5d2183bb5853
- https://git.kernel.org/stable/c/e2dabc4f7e7b60299c20a36d6a7b24ed9bf8e572
Modified: 2025-09-18
CVE-2021-47544
In the Linux kernel, the following vulnerability has been resolved: tcp: fix page frag corruption on page fault Steffen reported a TCP stream corruption for HTTP requests served by the apache web-server using a cifs mount-point and memory mapping the relevant file. The root cause is quite similar to the one addressed by commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from memory reclaim"). Here the nested access to the task page frag is caused by a page fault on the (mmapped) user-space memory buffer coming from the cifs file. The page fault handler performs an smb transaction on a different socket, inside the same process context. Since sk->sk_allaction for such socket does not prevent the usage for the task_frag, the nested allocation modify "under the hood" the page frag in use by the outer sendmsg call, corrupting the stream. The overall relevant stack trace looks like the following: httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked: ffffffff91461d91 tcp_sendmsg_locked+0x1 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139814e sock_sendmsg+0x3e ffffffffc06dfe1d smb_send_kvec+0x28 [...] ffffffffc06cfaf8 cifs_readpages+0x213 ffffffff90e83c4b read_pages+0x6b ffffffff90e83f31 __do_page_cache_readahead+0x1c1 ffffffff90e79e98 filemap_fault+0x788 ffffffff90eb0458 __do_fault+0x38 ffffffff90eb5280 do_fault+0x1a0 ffffffff90eb7c84 __handle_mm_fault+0x4d4 ffffffff90eb8093 handle_mm_fault+0xc3 ffffffff90c74f6d __do_page_fault+0x1ed ffffffff90c75277 do_page_fault+0x37 ffffffff9160111e page_fault+0x1e ffffffff9109e7b5 copyin+0x25 ffffffff9109eb40 _copy_from_iter_full+0xe0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139815c sock_sendmsg+0x4c ffffffff913981f7 sock_write_iter+0x97 ffffffff90f2cc56 do_iter_readv_writev+0x156 ffffffff90f2dff0 do_iter_write+0x80 ffffffff90f2e1c3 vfs_writev+0xa3 ffffffff90f2e27c do_writev+0x5c ffffffff90c042bb do_syscall_64+0x5b ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65 The cifs filesystem rightfully sets sk_allocations to GFP_NOFS, we can avoid the nesting using the sk page frag for allocation lacking the __GFP_FS flag. Do not define an additional mm-helper for that, as this is strictly tied to the sk page frag usage. v1 -> v2: - use a stricted sk_page_frag() check instead of reordering the code (Eric)
- https://git.kernel.org/stable/c/5a9afcd827cafe14a95c9fcbded2c2d104f18dfc
- https://git.kernel.org/stable/c/c6f340a331fb72e5ac23a083de9c780e132ca3ae
- https://git.kernel.org/stable/c/dacb5d8875cc6cd3a553363b4d6f06760fcbe70c
- https://git.kernel.org/stable/c/5a9afcd827cafe14a95c9fcbded2c2d104f18dfc
- https://git.kernel.org/stable/c/c6f340a331fb72e5ac23a083de9c780e132ca3ae
- https://git.kernel.org/stable/c/dacb5d8875cc6cd3a553363b4d6f06760fcbe70c
Modified: 2024-11-21
CVE-2021-47546
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix memory leak in fib6_rule_suppress The kernel leaks memory when a `fib` rule is present in IPv6 nftables firewall rules and a suppress_prefix rule is present in the IPv6 routing rules (used by certain tools such as wg-quick). In such scenarios, every incoming packet will leak an allocation in `ip6_dst_cache` slab cache. After some hours of `bpftrace`-ing and source code reading, I tracked down the issue to ca7a03c41753 ("ipv6: do not free rt if FIB_LOOKUP_NOREF is set on suppress rule"). The problem with that change is that the generic `args->flags` always have `FIB_LOOKUP_NOREF` set[1][2] but the IPv6-specific flag `RT6_LOOKUP_F_DST_NOREF` might not be, leading to `fib6_rule_suppress` not decreasing the refcount when needed. How to reproduce: - Add the following nftables rule to a prerouting chain: meta nfproto ipv6 fib saddr . mark . iif oif missing drop This can be done with: sudo nft create table inet test sudo nft create chain inet test test_chain '{ type filter hook prerouting priority filter + 10; policy accept; }' sudo nft add rule inet test test_chain meta nfproto ipv6 fib saddr . mark . iif oif missing drop - Run: sudo ip -6 rule add table main suppress_prefixlength 0 - Watch `sudo slabtop -o | grep ip6_dst_cache` to see memory usage increase with every incoming ipv6 packet. This patch exposes the protocol-specific flags to the protocol specific `suppress` function, and check the protocol-specific `flags` argument for RT6_LOOKUP_F_DST_NOREF instead of the generic FIB_LOOKUP_NOREF when decreasing the refcount, like this. [1]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L71 [2]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L99
- https://git.kernel.org/stable/c/209d35ee34e25f9668c404350a1c86d914c54ffa
- https://git.kernel.org/stable/c/8ef8a76a340ebdb2c2eea3f6fb0ebbed09a16383
- https://git.kernel.org/stable/c/cdef485217d30382f3bf6448c54b4401648fe3f1
- https://git.kernel.org/stable/c/ee38eb8cf9a7323884c2b8e0adbbeb2192d31e29
- https://git.kernel.org/stable/c/209d35ee34e25f9668c404350a1c86d914c54ffa
- https://git.kernel.org/stable/c/8ef8a76a340ebdb2c2eea3f6fb0ebbed09a16383
- https://git.kernel.org/stable/c/cdef485217d30382f3bf6448c54b4401648fe3f1
- https://git.kernel.org/stable/c/ee38eb8cf9a7323884c2b8e0adbbeb2192d31e29
Modified: 2025-04-01
CVE-2021-47547
In the Linux kernel, the following vulnerability has been resolved: net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the 'for' end, the 'k' is 8. At this time, the array 'lp->phy[8]' may be out of bound.
- https://git.kernel.org/stable/c/12f907cb11576b8cd0b1d95a16d1f10ed5bb7237
- https://git.kernel.org/stable/c/142ead3dc70411bd5977e8c47a6d8bf22287b3f8
- https://git.kernel.org/stable/c/2c1a6a9a011d622a7c61324a97a49801ba425eff
- https://git.kernel.org/stable/c/61217be886b5f7402843677e4be7e7e83de9cb41
- https://git.kernel.org/stable/c/77ff166909458646e66450e42909e0adacc99049
- https://git.kernel.org/stable/c/d3dedaa5a601107cfedda087209772c76e364d58
- https://git.kernel.org/stable/c/ec5bd0aef1cec96830d0c7e06d3597d9e786cc98
- https://git.kernel.org/stable/c/f059fa40f0fcc6bc7a12e0f2a2504e9a4ff74f1f
- https://git.kernel.org/stable/c/12f907cb11576b8cd0b1d95a16d1f10ed5bb7237
- https://git.kernel.org/stable/c/142ead3dc70411bd5977e8c47a6d8bf22287b3f8
- https://git.kernel.org/stable/c/2c1a6a9a011d622a7c61324a97a49801ba425eff
- https://git.kernel.org/stable/c/61217be886b5f7402843677e4be7e7e83de9cb41
- https://git.kernel.org/stable/c/77ff166909458646e66450e42909e0adacc99049
- https://git.kernel.org/stable/c/d3dedaa5a601107cfedda087209772c76e364d58
- https://git.kernel.org/stable/c/ec5bd0aef1cec96830d0c7e06d3597d9e786cc98
- https://git.kernel.org/stable/c/f059fa40f0fcc6bc7a12e0f2a2504e9a4ff74f1f
Modified: 2025-04-01
CVE-2021-47548
In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns.
- https://git.kernel.org/stable/c/22519eff7df2d88adcc2568d86046ce1e2b52803
- https://git.kernel.org/stable/c/948968f8747650447c8f21c9fdba0e1973be040b
- https://git.kernel.org/stable/c/99bb25cb6753beaf2c2bc37927c2ecc0ceff3f6d
- https://git.kernel.org/stable/c/a66998e0fbf213d47d02813b9679426129d0d114
- https://git.kernel.org/stable/c/abbd5faa0748d0aa95d5191d56ff7a17a6275bd1
- https://git.kernel.org/stable/c/dd07f8971b81ad98cc754b179b331b57f35aa1ff
- https://git.kernel.org/stable/c/fc7ffa7f10b9454a86369405d9814bf141b30627
- https://git.kernel.org/stable/c/22519eff7df2d88adcc2568d86046ce1e2b52803
- https://git.kernel.org/stable/c/948968f8747650447c8f21c9fdba0e1973be040b
- https://git.kernel.org/stable/c/99bb25cb6753beaf2c2bc37927c2ecc0ceff3f6d
- https://git.kernel.org/stable/c/a66998e0fbf213d47d02813b9679426129d0d114
- https://git.kernel.org/stable/c/abbd5faa0748d0aa95d5191d56ff7a17a6275bd1
- https://git.kernel.org/stable/c/dd07f8971b81ad98cc754b179b331b57f35aa1ff
- https://git.kernel.org/stable/c/fc7ffa7f10b9454a86369405d9814bf141b30627
Modified: 2025-01-07
CVE-2021-47549
In the Linux kernel, the following vulnerability has been resolved: sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux, a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Call Trace: .free_irq+0x1c/0x4e0 (unreliable) .ata_host_stop+0x74/0xd0 [libata] .release_nodes+0x330/0x3f0 .device_release_driver_internal+0x178/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] .__se_sys_delete_module+0x1ec/0x2d0 .system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 ================================================================== The triggering of the BUG is shown in the following stack: driver_detach device_release_driver_internal __device_release_driver drv->remove(dev) --> platform_drv_remove/platform_remove drv->remove(dev) --> sata_fsl_remove iounmap(host_priv->hcr_base); <---- unmap kfree(host_priv); <---- free devres_release_all release_nodes dr->node.release(dev, dr->data) --> ata_host_stop ap->ops->port_stop(ap) --> sata_fsl_port_stop ioread32(hcr_base + HCONTROL) <---- UAF host->ops->host_stop(host) The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should not be executed in drv->remove. These functions should be executed in host_stop after port_stop. Therefore, we move these functions to the new function sata_fsl_host_stop and bind the new function to host_stop.
- https://git.kernel.org/stable/c/0769449b0a5eabc3545337217ae690e46673e73a
- https://git.kernel.org/stable/c/325ea49fc43cbc03a5e1e37de8f0ca6357ced4b1
- https://git.kernel.org/stable/c/4a46b2f5dce02539e88a300800812bd24a45e097
- https://git.kernel.org/stable/c/6c8ad7e8cf29eb55836e7a0215f967746ab2b504
- https://git.kernel.org/stable/c/77393806c76b6b44f1c44bd957788c8bd9152c45
- https://git.kernel.org/stable/c/91ba94d3f7afca195b224f77a72044fbde1389ce
- https://git.kernel.org/stable/c/adf098e2a8a1e1fc075d6a5ba2edd13cf7189082
- https://git.kernel.org/stable/c/cdcd80292106df5cda325426e96495503e41f947
- https://git.kernel.org/stable/c/0769449b0a5eabc3545337217ae690e46673e73a
- https://git.kernel.org/stable/c/325ea49fc43cbc03a5e1e37de8f0ca6357ced4b1
- https://git.kernel.org/stable/c/4a46b2f5dce02539e88a300800812bd24a45e097
- https://git.kernel.org/stable/c/6c8ad7e8cf29eb55836e7a0215f967746ab2b504
- https://git.kernel.org/stable/c/77393806c76b6b44f1c44bd957788c8bd9152c45
- https://git.kernel.org/stable/c/91ba94d3f7afca195b224f77a72044fbde1389ce
- https://git.kernel.org/stable/c/adf098e2a8a1e1fc075d6a5ba2edd13cf7189082
- https://git.kernel.org/stable/c/cdcd80292106df5cda325426e96495503e41f947
Modified: 2024-11-21
CVE-2021-47550
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: fix potential memleak In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed There is a potential memleak if not call kobject_put.
- https://git.kernel.org/stable/c/27dfaedc0d321b4ea4e10c53e4679d6911ab17aa
- https://git.kernel.org/stable/c/75752ada77e0726327adf68018b9f50ae091baeb
- https://git.kernel.org/stable/c/c746945fb6bcbe3863c9ea6369c7ef376e38e5eb
- https://git.kernel.org/stable/c/27dfaedc0d321b4ea4e10c53e4679d6911ab17aa
- https://git.kernel.org/stable/c/75752ada77e0726327adf68018b9f50ae091baeb
- https://git.kernel.org/stable/c/c746945fb6bcbe3863c9ea6369c7ef376e38e5eb
Modified: 2025-04-01
CVE-2021-47551
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again In SRIOV configuration, the reset may failed to bring asic back to normal but stop cpsch already been called, the start_cpsch will not be called since there is no resume in this case. When reset been triggered again, driver should avoid to do uninitialization again.
- https://git.kernel.org/stable/c/06c6f8f86ec243b89e52f0c3dc7062bcb9de74df
- https://git.kernel.org/stable/c/2cf49e00d40d5132e3d067b5aa6d84791929ab15
- https://git.kernel.org/stable/c/74aafe99efb68f15e50be9f7032c2168512f98a8
- https://git.kernel.org/stable/c/06c6f8f86ec243b89e52f0c3dc7062bcb9de74df
- https://git.kernel.org/stable/c/2cf49e00d40d5132e3d067b5aa6d84791929ab15
- https://git.kernel.org/stable/c/74aafe99efb68f15e50be9f7032c2168512f98a8
Modified: 2025-01-06
CVE-2021-47552
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()
For avoiding to slow down queue destroy, we don't call
blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to
cancel dispatch work in blk_release_queue().
However, this way has caused kernel oops[1], reported by Changhui. The log
shows that scsi_device can be freed before running blk_release_queue(),
which is expected too since scsi_device is released after the scsi disk
is closed and the scsi_device is removed.
Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue()
and disk_release():
1) when disk_release() is run, the disk has been closed, and any sync
dispatch activities have been done, so canceling dispatch work is enough to
quiesce filesystem I/O dispatch activity.
2) in blk_cleanup_queue(), we only focus on passthrough request, and
passthrough request is always explicitly allocated & freed by
its caller, so once queue is frozen, all sync dispatch activity
for passthrough request has been done, then it is enough to just cancel
dispatch work for avoiding any dispatch activity.
[1] kernel panic log
[12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300
[12622.777186] #PF: supervisor read access in kernel mode
[12622.782918] #PF: error_code(0x0000) - not-present page
[12622.788649] PGD 0 P4D 0
[12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI
[12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1
[12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015
[12622.813321] Workqueue: kblockd blk_mq_run_work_fn
[12622.818572] RIP: 0010:sbitmap_get+0x75/0x190
[12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 <48> 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58
[12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202
[12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004
[12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030
[12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334
[12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000
[12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030
[12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000
[12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0
[12622.913328] Call Trace:
[12622.916055]
Modified: 2025-09-18
CVE-2021-47553
In the Linux kernel, the following vulnerability has been resolved: sched/scs: Reset task stack state in bringup_cpu() To hot unplug a CPU, the idle task on that CPU calls a few layers of C code before finally leaving the kernel. When KASAN is in use, poisoned shadow is left around for each of the active stack frames, and when shadow call stacks are in use. When shadow call stacks (SCS) are in use the task's saved SCS SP is left pointing at an arbitrary point within the task's shadow call stack. When a CPU is offlined than onlined back into the kernel, this stale state can adversely affect execution. Stale KASAN shadow can alias new stackframes and result in bogus KASAN warnings. A stale SCS SP is effectively a memory leak, and prevents a portion of the shadow call stack being used. Across a number of hotplug cycles the idle task's entire shadow call stack can become unusable. We previously fixed the KASAN issue in commit: e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug") ... by removing any stale KASAN stack poison immediately prior to onlining a CPU. Subsequently in commit: f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled") ... the refactoring left the KASAN and SCS cleanup in one-time idle thread initialization code rather than something invoked prior to each CPU being onlined, breaking both as above. We fixed SCS (but not KASAN) in commit: 63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit") ... but as this runs in the context of the idle task being offlined it's potentially fragile. To fix these consistently and more robustly, reset the SCS SP and KASAN shadow of a CPU's idle task immediately before we online that CPU in bringup_cpu(). This ensures the idle task always has a consistent state when it is running, and removes the need to so so when exiting an idle task. Whenever any thread is created, dup_task_struct() will give the task a stack which is free of KASAN shadow, and initialize the task's SCS SP, so there's no need to specially initialize either for idle thread within init_idle(), as this was only necessary to handle hotplug cycles. I've tested this on arm64 with: * gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK * clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK ... offlining and onlining CPUS with: | while true; do | for C in /sys/devices/system/cpu/cpu*/online; do | echo 0 > $C; | echo 1 > $C; | done | done
- https://git.kernel.org/stable/c/229c555260cb9c1ccdab861e16f0410f1718f302
- https://git.kernel.org/stable/c/dce1ca0525bfdc8a69a9343bc714fbc19a2f04b3
- https://git.kernel.org/stable/c/e6ee7abd6bfe559ad9989004b34c320fd638c526
- https://git.kernel.org/stable/c/229c555260cb9c1ccdab861e16f0410f1718f302
- https://git.kernel.org/stable/c/dce1ca0525bfdc8a69a9343bc714fbc19a2f04b3
- https://git.kernel.org/stable/c/e6ee7abd6bfe559ad9989004b34c320fd638c526
Modified: 2025-01-15
CVE-2021-47554
In the Linux kernel, the following vulnerability has been resolved:
vdpa_sim: avoid putting an uninitialized iova_domain
The system will crash if we put an uninitialized iova_domain, this
could happen when an error occurs before initializing the iova_domain
in vdpasim_create().
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
RIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0
...
Call Trace:
Modified: 2025-09-18
CVE-2021-47555
In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix underflow for the real_dev refcnt Inject error before dev_hold(real_dev) in register_vlan_dev(), and execute the following testcase: ip link add dev dummy1 type dummy ip link add name dummy1.100 link dummy1 type vlan id 100 ip link del dev dummy1 When the dummy netdevice is removed, we will get a WARNING as following: ======================================================================= refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 2 PID: 0 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 and an endless loop of: ======================================================================= unregister_netdevice: waiting for dummy1 to become free. Usage count = -1073741824 That is because dev_put(real_dev) in vlan_dev_free() be called without dev_hold(real_dev) in register_vlan_dev(). It makes the refcnt of real_dev underflow. Move the dev_hold(real_dev) to vlan_dev_init() which is the call-back of ndo_init(). That makes dev_hold() and dev_put() for vlan's real_dev symmetrical.
- https://git.kernel.org/stable/c/01d9cc2dea3fde3bad6d27f464eff463496e2b00
- https://git.kernel.org/stable/c/5e44178864b38dd70b877985abd7d86fdb95f27d
- https://git.kernel.org/stable/c/6e800ee43218a56acc93676bbb3d93b74779e555
- https://git.kernel.org/stable/c/f7fc72a508cf115c273a7a29350069def1041890
- https://git.kernel.org/stable/c/01d9cc2dea3fde3bad6d27f464eff463496e2b00
- https://git.kernel.org/stable/c/5e44178864b38dd70b877985abd7d86fdb95f27d
- https://git.kernel.org/stable/c/6e800ee43218a56acc93676bbb3d93b74779e555
- https://git.kernel.org/stable/c/f7fc72a508cf115c273a7a29350069def1041890
Modified: 2024-11-21
CVE-2021-47556
In the Linux kernel, the following vulnerability has been resolved: ethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce() ethtool_set_coalesce() now uses both the .get_coalesce() and .set_coalesce() callbacks. But the check for their availability is buggy, so changing the coalesce settings on a device where the driver provides only _one_ of the callbacks results in a NULL pointer dereference instead of an -EOPNOTSUPP. Fix the condition so that the availability of both callbacks is ensured. This also matches the netlink code. Note that reproducing this requires some effort - it only affects the legacy ioctl path, and needs a specific combination of driver options: - have .get_coalesce() and .coalesce_supported but no .set_coalesce(), or - have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn't cause the crash as it first attempts to call ethtool_get_coalesce() and bails out on error.
Modified: 2025-01-06
CVE-2021-47557
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_ets: don't peek at classes beyond 'nbands'
when the number of DRR classes decreases, the round-robin active list can
contain elements that have already been freed in ets_qdisc_change(). As a
consequence, it's possible to see a NULL dereference crash, caused by the
attempt to call cl->qdisc->ops->peek(cl->qdisc) when cl->qdisc is NULL:
BUG: kernel NULL pointer dereference, address: 0000000000000018
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 910 Comm: mausezahn Not tainted 5.16.0-rc1+ #475
Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
RIP: 0010:ets_qdisc_dequeue+0x129/0x2c0 [sch_ets]
Code: c5 01 41 39 ad e4 02 00 00 0f 87 18 ff ff ff 49 8b 85 c0 02 00 00 49 39 c4 0f 84 ba 00 00 00 49 8b ad c0 02 00 00 48 8b 7d 10 <48> 8b 47 18 48 8b 40 38 0f ae e8 ff d0 48 89 c3 48 85 c0 0f 84 9d
RSP: 0000:ffffbb36c0b5fdd8 EFLAGS: 00010287
RAX: ffff956678efed30 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000002 RSI: ffffffff9b938dc9 RDI: 0000000000000000
RBP: ffff956678efed30 R08: e2f3207fe360129c R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: ffff956678efeac0
R13: ffff956678efe800 R14: ffff956611545000 R15: ffff95667ac8f100
FS: 00007f2aa9120740(0000) GS:ffff95667b800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000011070c000 CR4: 0000000000350ee0
Call Trace:
- https://git.kernel.org/stable/c/ae2659d2c670252759ee9c823c4e039c0e05a6f2
- https://git.kernel.org/stable/c/de6d25924c2a8c2988c6a385990cafbe742061bf
- https://git.kernel.org/stable/c/e25bdbc7e951ae5728fee1f4c09485df113d013c
- https://git.kernel.org/stable/c/ae2659d2c670252759ee9c823c4e039c0e05a6f2
- https://git.kernel.org/stable/c/de6d25924c2a8c2988c6a385990cafbe742061bf
- https://git.kernel.org/stable/c/e25bdbc7e951ae5728fee1f4c09485df113d013c
Modified: 2025-09-18
CVE-2021-47558
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Disable Tx queues when reconfiguring the interface The Tx queues were not disabled in situations where the driver needed to stop the interface to apply a new configuration. This could result in a kernel panic when doing any of the 3 following actions: * reconfiguring the number of queues (ethtool -L) * reconfiguring the size of the ring buffers (ethtool -G) * installing/removing an XDP program (ip l set dev ethX xdp) Prevent the panic by making sure netif_tx_disable is called when stopping an interface. Without this patch, the following kernel panic can be observed when doing any of the actions above: Unable to handle kernel paging request at virtual address ffff80001238d040 [....] Call trace: dwmac4_set_addr+0x8/0x10 dev_hard_start_xmit+0xe4/0x1ac sch_direct_xmit+0xe8/0x39c __dev_queue_xmit+0x3ec/0xaf0 dev_queue_xmit+0x14/0x20 [...] [ end trace 0000000000000002 ]---
Modified: 2024-11-21
CVE-2021-47559
In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk() Coverity reports a possible NULL dereferencing problem: in smc_vlan_by_tcpsk(): 6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times). 7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next. 1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower); CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS) 8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev. 1624 if (is_vlan_dev(ndev)) { Remove the manual implementation and use netdev_walk_all_lower_dev() to iterate over the lower devices. While on it remove an obsolete function parameter comment.
- https://git.kernel.org/stable/c/587acad41f1bc48e16f42bb2aca63bf323380be8
- https://git.kernel.org/stable/c/bb851d0fb02547d03cd40106b5f2391c4fed6ed1
- https://git.kernel.org/stable/c/c94cbd262b6aa3b54d73a1ed1f9c0d19df57f4ff
- https://git.kernel.org/stable/c/587acad41f1bc48e16f42bb2aca63bf323380be8
- https://git.kernel.org/stable/c/bb851d0fb02547d03cd40106b5f2391c4fed6ed1
- https://git.kernel.org/stable/c/c94cbd262b6aa3b54d73a1ed1f9c0d19df57f4ff
Modified: 2025-01-06
CVE-2021-47560
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum: Protect driver from buggy firmware When processing port up/down events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not the CPU port (local port 0), which exists, but lacks a netdev. This can result in a NULL pointer dereference when calling netif_carrier_{on,off}(). Fix this by bailing early when processing an event reported for the CPU port. Problem was only observed when running on top of a buggy emulator.
- https://git.kernel.org/stable/c/63b08b1f6834bbb0b4f7783bf63b80c8c8e9a047
- https://git.kernel.org/stable/c/90d0736876c50ecde1a3275636a06b9ddb1cace9
- https://git.kernel.org/stable/c/da4d70199e5d82da664a80077508d6c18f5e76df
- https://git.kernel.org/stable/c/63b08b1f6834bbb0b4f7783bf63b80c8c8e9a047
- https://git.kernel.org/stable/c/90d0736876c50ecde1a3275636a06b9ddb1cace9
- https://git.kernel.org/stable/c/da4d70199e5d82da664a80077508d6c18f5e76df
Modified: 2025-09-18
CVE-2021-47561
In the Linux kernel, the following vulnerability has been resolved: i2c: virtio: disable timeout handling If a timeout is hit, it can result is incorrect data on the I2C bus and/or memory corruptions in the guest since the device can still be operating on the buffers it was given while the guest has freed them. Here is, for example, the start of a slub_debug splat which was triggered on the next transfer after one transfer was forced to timeout by setting a breakpoint in the backend (rust-vmm/vhost-device): BUG kmalloc-1k (Not tainted): Poison overwritten First byte 0x1 instead of 0x6b Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29 kfree+0x1bd/0x1cc virtio_i2c_xfer+0x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 There is no simple fix for this (the driver would have to always create bounce buffers and hold on to them until the device eventually returns the buffers), so just disable the timeout support for now.
Modified: 2025-01-06
CVE-2021-47562
In the Linux kernel, the following vulnerability has been resolved: ice: fix vsi->txq_map sizing The approach of having XDP queue per CPU regardless of user's setting exposed a hidden bug that could occur in case when Rx queue count differ from Tx queue count. Currently vsi->txq_map's size is equal to the doubled vsi->alloc_txq, which is not correct due to the fact that XDP rings were previously based on the Rx queue count. Below splat can be seen when ethtool -L is used and XDP rings are configured: [ 682.875339] BUG: kernel NULL pointer dereference, address: 000000000000000f [ 682.883403] #PF: supervisor read access in kernel mode [ 682.889345] #PF: error_code(0x0000) - not-present page [ 682.895289] PGD 0 P4D 0 [ 682.898218] Oops: 0000 [#1] PREEMPT SMP PTI [ 682.903055] CPU: 42 PID: 2878 Comm: ethtool Tainted: G OE 5.15.0-rc5+ #1 [ 682.912214] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [ 682.923380] RIP: 0010:devres_remove+0x44/0x130 [ 682.928527] Code: 49 89 f4 55 48 89 fd 4c 89 ff 53 48 83 ec 10 e8 92 b9 49 00 48 8b 9d a8 02 00 00 48 8d 8d a0 02 00 00 49 89 c2 48 39 cb 74 0f <4c> 3b 63 10 74 25 48 8b 5b 08 48 39 cb 75 f1 4c 89 ff 4c 89 d6 e8 [ 682.950237] RSP: 0018:ffffc90006a679f0 EFLAGS: 00010002 [ 682.956285] RAX: 0000000000000286 RBX: ffffffffffffffff RCX: ffff88908343a370 [ 682.964538] RDX: 0000000000000001 RSI: ffffffff81690d60 RDI: 0000000000000000 [ 682.972789] RBP: ffff88908343a0d0 R08: 0000000000000000 R09: 0000000000000000 [ 682.981040] R10: 0000000000000286 R11: 3fffffffffffffff R12: ffffffff81690d60 [ 682.989282] R13: ffffffff81690a00 R14: ffff8890819807a8 R15: ffff88908343a36c [ 682.997535] FS: 00007f08c7bfa740(0000) GS:ffff88a03fd00000(0000) knlGS:0000000000000000 [ 683.006910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 683.013557] CR2: 000000000000000f CR3: 0000001080a66003 CR4: 00000000003706e0 [ 683.021819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 683.030075] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 683.038336] Call Trace: [ 683.041167] devm_kfree+0x33/0x50 [ 683.045004] ice_vsi_free_arrays+0x5e/0xc0 [ice] [ 683.050380] ice_vsi_rebuild+0x4c8/0x750 [ice] [ 683.055543] ice_vsi_recfg_qs+0x9a/0x110 [ice] [ 683.060697] ice_set_channels+0x14f/0x290 [ice] [ 683.065962] ethnl_set_channels+0x333/0x3f0 [ 683.070807] genl_family_rcv_msg_doit+0xea/0x150 [ 683.076152] genl_rcv_msg+0xde/0x1d0 [ 683.080289] ? channels_prepare_data+0x60/0x60 [ 683.085432] ? genl_get_cmd+0xd0/0xd0 [ 683.089667] netlink_rcv_skb+0x50/0xf0 [ 683.094006] genl_rcv+0x24/0x40 [ 683.097638] netlink_unicast+0x239/0x340 [ 683.102177] netlink_sendmsg+0x22e/0x470 [ 683.106717] sock_sendmsg+0x5e/0x60 [ 683.110756] __sys_sendto+0xee/0x150 [ 683.114894] ? handle_mm_fault+0xd0/0x2a0 [ 683.119535] ? do_user_addr_fault+0x1f3/0x690 [ 683.134173] __x64_sys_sendto+0x25/0x30 [ 683.148231] do_syscall_64+0x3b/0xc0 [ 683.161992] entry_SYSCALL_64_after_hwframe+0x44/0xae Fix this by taking into account the value that num_possible_cpus() yields in addition to vsi->alloc_txq instead of doubling the latter.
- https://git.kernel.org/stable/c/1eb5395add786613c7c5579d3947aa0b8f0ec241
- https://git.kernel.org/stable/c/792b2086584f25d84081a526beee80d103c2a913
- https://git.kernel.org/stable/c/992ba40a67638dfe2772b84dfc8168dc328d5c4c
- https://git.kernel.org/stable/c/1eb5395add786613c7c5579d3947aa0b8f0ec241
- https://git.kernel.org/stable/c/792b2086584f25d84081a526beee80d103c2a913
- https://git.kernel.org/stable/c/992ba40a67638dfe2772b84dfc8168dc328d5c4c
Modified: 2025-04-01
CVE-2021-47563
In the Linux kernel, the following vulnerability has been resolved: ice: avoid bpf_prog refcount underflow Ice driver has the routines for managing XDP resources that are shared between ndo_bpf op and VSI rebuild flow. The latter takes place for example when user changes queue count on an interface via ethtool's set_channels(). There is an issue around the bpf_prog refcounting when VSI is being rebuilt - since ice_prepare_xdp_rings() is called with vsi->xdp_prog as an argument that is used later on by ice_vsi_assign_bpf_prog(), same bpf_prog pointers are swapped with each other. Then it is also interpreted as an 'old_prog' which in turn causes us to call bpf_prog_put on it that will decrement its refcount. Below splat can be interpreted in a way that due to zero refcount of a bpf_prog it is wiped out from the system while kernel still tries to refer to it: [ 481.069429] BUG: unable to handle page fault for address: ffffc9000640f038 [ 481.077390] #PF: supervisor read access in kernel mode [ 481.083335] #PF: error_code(0x0000) - not-present page [ 481.089276] PGD 100000067 P4D 100000067 PUD 1001cb067 PMD 106d2b067 PTE 0 [ 481.097141] Oops: 0000 [#1] PREEMPT SMP PTI [ 481.101980] CPU: 12 PID: 3339 Comm: sudo Tainted: G OE 5.15.0-rc5+ #1 [ 481.110840] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [ 481.122021] RIP: 0010:dev_xdp_prog_id+0x25/0x40 [ 481.127265] Code: 80 00 00 00 00 0f 1f 44 00 00 89 f6 48 c1 e6 04 48 01 fe 48 8b 86 98 08 00 00 48 85 c0 74 13 48 8b 50 18 31 c0 48 85 d2 74 07 <48> 8b 42 38 8b 40 20 c3 48 8b 96 90 08 00 00 eb e8 66 2e 0f 1f 84 [ 481.148991] RSP: 0018:ffffc90007b63868 EFLAGS: 00010286 [ 481.155034] RAX: 0000000000000000 RBX: ffff889080824000 RCX: 0000000000000000 [ 481.163278] RDX: ffffc9000640f000 RSI: ffff889080824010 RDI: ffff889080824000 [ 481.171527] RBP: ffff888107af7d00 R08: 0000000000000000 R09: ffff88810db5f6e0 [ 481.179776] R10: 0000000000000000 R11: ffff8890885b9988 R12: ffff88810db5f4bc [ 481.188026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 481.196276] FS: 00007f5466d5bec0(0000) GS:ffff88903fb00000(0000) knlGS:0000000000000000 [ 481.205633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 481.212279] CR2: ffffc9000640f038 CR3: 000000014429c006 CR4: 00000000003706e0 [ 481.220530] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 481.228771] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 481.237029] Call Trace: [ 481.239856] rtnl_fill_ifinfo+0x768/0x12e0 [ 481.244602] rtnl_dump_ifinfo+0x525/0x650 [ 481.249246] ? __alloc_skb+0xa5/0x280 [ 481.253484] netlink_dump+0x168/0x3c0 [ 481.257725] netlink_recvmsg+0x21e/0x3e0 [ 481.262263] ____sys_recvmsg+0x87/0x170 [ 481.266707] ? __might_fault+0x20/0x30 [ 481.271046] ? _copy_from_user+0x66/0xa0 [ 481.275591] ? iovec_from_user+0xf6/0x1c0 [ 481.280226] ___sys_recvmsg+0x82/0x100 [ 481.284566] ? sock_sendmsg+0x5e/0x60 [ 481.288791] ? __sys_sendto+0xee/0x150 [ 481.293129] __sys_recvmsg+0x56/0xa0 [ 481.297267] do_syscall_64+0x3b/0xc0 [ 481.301395] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 481.307238] RIP: 0033:0x7f5466f39617 [ 481.311373] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bd 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2f 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 [ 481.342944] RSP: 002b:00007ffedc7f4308 EFLAGS: 00000246 ORIG_RAX: 000000000000002f [ 481.361783] RAX: ffffffffffffffda RBX: 00007ffedc7f5460 RCX: 00007f5466f39617 [ 481.380278] RDX: 0000000000000000 RSI: 00007ffedc7f5360 RDI: 0000000000000003 [ 481.398500] RBP: 00007ffedc7f53f0 R08: 0000000000000000 R09: 000055d556f04d50 [ 481.416463] R10: 0000000000000077 R11: 0000000000000246 R12: 00007ffedc7f5360 [ 481.434131] R13: 00007ffedc7f5350 R14: 00007ffedc7f5344 R15: 0000000000000e98 [ 481.451520] Modules linked in: ice ---truncated---
- https://git.kernel.org/stable/c/1f10b09ccc832698ef4624a6ab9a213b6ccbda76
- https://git.kernel.org/stable/c/e65a8707b4cd756d26d246bb2b9fab06eebafac1
- https://git.kernel.org/stable/c/f65ee535df775a13a1046c0a0b2d72db342f8a5b
- https://git.kernel.org/stable/c/1f10b09ccc832698ef4624a6ab9a213b6ccbda76
- https://git.kernel.org/stable/c/e65a8707b4cd756d26d246bb2b9fab06eebafac1
- https://git.kernel.org/stable/c/f65ee535df775a13a1046c0a0b2d72db342f8a5b
Modified: 2025-01-06
CVE-2021-47564
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix double free issue on err path fix error path handling in prestera_bridge_port_join() that cases prestera driver to crash (see below). Trace: Internal error: Oops: 96000044 [#1] SMP Modules linked in: prestera_pci prestera uio_pdrv_genirq CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : prestera_bridge_destroy+0x2c/0xb0 [prestera] lr : prestera_bridge_port_join+0x2cc/0x350 [prestera] sp : ffff800011a1b0f0 ... x2 : ffff000109ca6c80 x1 : dead000000000100 x0 : dead000000000122 Call trace: prestera_bridge_destroy+0x2c/0xb0 [prestera] prestera_bridge_port_join+0x2cc/0x350 [prestera] prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera] prestera_netdev_event_handler+0xf4/0x110 [prestera] raw_notifier_call_chain+0x54/0x80 call_netdevice_notifiers_info+0x54/0xa0 __netdev_upper_dev_link+0x19c/0x380
- https://git.kernel.org/stable/c/03e5203d2161a00afe4d97d206d2293e40b2f253
- https://git.kernel.org/stable/c/5dca8eff4627315df98feec09fff9dfe3356325e
- https://git.kernel.org/stable/c/e8d032507cb7912baf1d3e0af54516f823befefd
- https://git.kernel.org/stable/c/03e5203d2161a00afe4d97d206d2293e40b2f253
- https://git.kernel.org/stable/c/5dca8eff4627315df98feec09fff9dfe3356325e
- https://git.kernel.org/stable/c/e8d032507cb7912baf1d3e0af54516f823befefd
Modified: 2025-09-18
CVE-2021-47565
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix kernel panic during drive powercycle test While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL.
- https://git.kernel.org/stable/c/0d4b29eaadc1f59cec0c7e85eae77d08fcca9824
- https://git.kernel.org/stable/c/0ee4ba13e09c9d9c1cb6abb59da8295d9952328b
- https://git.kernel.org/stable/c/2bf9c5a5039c8f4b037236aed505e6a25c1d5f7b
- https://git.kernel.org/stable/c/58ef2c7a6de13721865d84b80eecf56d6cba0937
- https://git.kernel.org/stable/c/5d4d50b1f159a5ebab7617f47121b4370aa58afe
- https://git.kernel.org/stable/c/7e324f734a914957b8cc3ff4b4c9f0409558adb5
- https://git.kernel.org/stable/c/8485649a7655e791a6e4e9f15b4d30fdae937184
- https://git.kernel.org/stable/c/dd035ca0e7a142870a970d46b1d19276cfe2bc8c
- https://git.kernel.org/stable/c/0d4b29eaadc1f59cec0c7e85eae77d08fcca9824
- https://git.kernel.org/stable/c/0ee4ba13e09c9d9c1cb6abb59da8295d9952328b
- https://git.kernel.org/stable/c/2bf9c5a5039c8f4b037236aed505e6a25c1d5f7b
- https://git.kernel.org/stable/c/58ef2c7a6de13721865d84b80eecf56d6cba0937
- https://git.kernel.org/stable/c/5d4d50b1f159a5ebab7617f47121b4370aa58afe
- https://git.kernel.org/stable/c/7e324f734a914957b8cc3ff4b4c9f0409558adb5
- https://git.kernel.org/stable/c/8485649a7655e791a6e4e9f15b4d30fdae937184
- https://git.kernel.org/stable/c/dd035ca0e7a142870a970d46b1d19276cfe2bc8c
Modified: 2025-09-18
CVE-2021-47566
In the Linux kernel, the following vulnerability has been resolved: proc/vmcore: fix clearing user buffer by properly using clear_user() To clear a user buffer we cannot simply use memset, we have to use clear_user(). With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[465]: saving vmcore-dmesg.txt complete kdump[467]: saving vmcore BUG: unable to handle page fault for address: 00007f2374e01000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86 Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81 RSP: 0018:ffffc9000073be08 EFLAGS: 00010212 RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000 RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008 RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Call Trace: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 ksys_read+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access Prevention (SMAP)", which is used to detect wrong access from the kernel to user buffers like this: SMAP triggers a permissions violation on wrong access. In the x86-64 variant of clear_user(), SMAP is properly handled via clac()+stac(). To fix, properly use clear_user() when we're dealing with a user buffer.
- https://git.kernel.org/stable/c/33a7d698f30fa0b99d50569e9909d3baa65d8f6a
- https://git.kernel.org/stable/c/7b3a34f08d11e7f05cd00b8e09adaa15192f0ad1
- https://git.kernel.org/stable/c/99d348b82bcb36171f24411d3f1a15706a2a937a
- https://git.kernel.org/stable/c/9ef384ed300d1bcfb23d0ab0b487d544444d4b52
- https://git.kernel.org/stable/c/a8a917058faf4abaec9fb614bb6d5f8fe3529ec6
- https://git.kernel.org/stable/c/a9e164bd160be8cbee1df70acb379129e3cd2e7c
- https://git.kernel.org/stable/c/c1e63117711977cc4295b2ce73de29dd17066c82
- https://git.kernel.org/stable/c/fd7974c547abfb03072a4ee706d3a6f182266f89
- https://git.kernel.org/stable/c/33a7d698f30fa0b99d50569e9909d3baa65d8f6a
- https://git.kernel.org/stable/c/7b3a34f08d11e7f05cd00b8e09adaa15192f0ad1
- https://git.kernel.org/stable/c/99d348b82bcb36171f24411d3f1a15706a2a937a
- https://git.kernel.org/stable/c/9ef384ed300d1bcfb23d0ab0b487d544444d4b52
- https://git.kernel.org/stable/c/a8a917058faf4abaec9fb614bb6d5f8fe3529ec6
- https://git.kernel.org/stable/c/a9e164bd160be8cbee1df70acb379129e3cd2e7c
- https://git.kernel.org/stable/c/c1e63117711977cc4295b2ce73de29dd17066c82
- https://git.kernel.org/stable/c/fd7974c547abfb03072a4ee706d3a6f182266f89
Modified: 2025-09-18
CVE-2021-47567
In the Linux kernel, the following vulnerability has been resolved: powerpc/32: Fix hardlockup on vmap stack overflow Since the commit c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not activate MMU before reading task struct") a vmap stack overflow results in a hard lockup. This is because emergency_ctx is still addressed with its virtual address allthough data MMU is not active anymore at that time. Fix it by using a physical address instead.
- https://git.kernel.org/stable/c/5bb60ea611db1e04814426ed4bd1c95d1487678e
- https://git.kernel.org/stable/c/c4e3ff8b8b1d54f0c755670174c453b06e17114b
- https://git.kernel.org/stable/c/dfe906da9a1abebdebe8b15bb3e66a2578f6c4c7
- https://git.kernel.org/stable/c/5bb60ea611db1e04814426ed4bd1c95d1487678e
- https://git.kernel.org/stable/c/c4e3ff8b8b1d54f0c755670174c453b06e17114b
- https://git.kernel.org/stable/c/dfe906da9a1abebdebe8b15bb3e66a2578f6c4c7
Modified: 2025-01-06
CVE-2021-47568
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix memleak in get_file_stream_info() Fix memleak in get_file_stream_info()
Modified: 2025-09-29
CVE-2021-47569
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fail cancellation for EXITING tasks
WARNING: CPU: 1 PID: 20 at fs/io_uring.c:6269 io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269
CPU: 1 PID: 20 Comm: kworker/1:0 Not tainted 5.16.0-rc1-syzkaller #0
Workqueue: events io_fallback_req_func
RIP: 0010:io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269
Call Trace:
Modified: 2024-11-21
CVE-2021-47570
In the Linux kernel, the following vulnerability has been resolved: staging: r8188eu: fix a memory leak in rtw_wx_read32() Free "ptmp" before returning -EINVAL.
Modified: 2024-11-21
CVE-2021-47571
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect() The free_rtllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that.
- https://git.kernel.org/stable/c/2e1ec01af2c7139c6a600bbfaea1a018b35094b6
- https://git.kernel.org/stable/c/8d0163cec7de995f9eb9c3128c83fb84f0cb1c64
- https://git.kernel.org/stable/c/9186680382934b0e7529d3d70dcc0a21d087683b
- https://git.kernel.org/stable/c/b535917c51acc97fb0761b1edec85f1f3d02bda4
- https://git.kernel.org/stable/c/bca19bb2dc2d89ce60c4a4a6e59609d4cf2e13ef
- https://git.kernel.org/stable/c/c0ef0e75a858cbd8618b473f22fbca36106dcf82
- https://git.kernel.org/stable/c/d43aecb694b10db9a4228ce2d38b5ae8de374443
- https://git.kernel.org/stable/c/e27ee2f607fe6a9b923ef1fc65461c0613c97594
- https://git.kernel.org/stable/c/2e1ec01af2c7139c6a600bbfaea1a018b35094b6
- https://git.kernel.org/stable/c/8d0163cec7de995f9eb9c3128c83fb84f0cb1c64
- https://git.kernel.org/stable/c/9186680382934b0e7529d3d70dcc0a21d087683b
- https://git.kernel.org/stable/c/b535917c51acc97fb0761b1edec85f1f3d02bda4
- https://git.kernel.org/stable/c/bca19bb2dc2d89ce60c4a4a6e59609d4cf2e13ef
- https://git.kernel.org/stable/c/c0ef0e75a858cbd8618b473f22fbca36106dcf82
- https://git.kernel.org/stable/c/d43aecb694b10db9a4228ce2d38b5ae8de374443
- https://git.kernel.org/stable/c/e27ee2f607fe6a9b923ef1fc65461c0613c97594
Modified: 2024-11-21
CVE-2021-47572
In the Linux kernel, the following vulnerability has been resolved:
net: nexthop: fix null pointer dereference when IPv6 is not enabled
When we try to add an IPv6 nexthop and IPv6 is not enabled
(!CONFIG_IPV6) we'll hit a NULL pointer dereference[1] in the error path
of nh_create_ipv6() due to calling ipv6_stub->fib6_nh_release. The bug
has been present since the beginning of IPv6 nexthop gateway support.
Commit 1aefd3de7bc6 ("ipv6: Add fib6_nh_init and release to stubs") tells
us that only fib6_nh_init has a dummy stub because fib6_nh_release should
not be called if fib6_nh_init returns an error, but the commit below added
a call to ipv6_stub->fib6_nh_release in its error path. To fix it return
the dummy stub's -EAFNOSUPPORT error directly without calling
ipv6_stub->fib6_nh_release in nh_create_ipv6()'s error path.
[1]
Output is a bit truncated, but it clearly shows the error.
BUG: kernel NULL pointer dereference, address: 000000000000000000
#PF: supervisor instruction fetch in kernel modede
#PF: error_code(0x0010) - not-present pagege
PGD 0 P4D 0
Oops: 0010 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 638 Comm: ip Kdump: loaded Not tainted 5.16.0-rc1+ #446
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
RIP: 0010:0x0
Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
RSP: 0018:ffff888109f5b8f0 EFLAGS: 00010286^Ac
RAX: 0000000000000000 RBX: ffff888109f5ba28 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8881008a2860
RBP: ffff888109f5b9d8 R08: 0000000000000000 R09: 0000000000000000
R10: ffff888109f5b978 R11: ffff888109f5b948 R12: 00000000ffffff9f
R13: ffff8881008a2a80 R14: ffff8881008a2860 R15: ffff8881008a2840
FS: 00007f98de70f100(0000) GS:ffff88822bf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 0000000100efc000 CR4: 00000000000006e0
Call Trace:
- https://git.kernel.org/stable/c/1c743127cc54b112b155f434756bd4b5fa565a99
- https://git.kernel.org/stable/c/39509d76a9a3d02f379d52cb4b1449469c56c0e0
- https://git.kernel.org/stable/c/7b6f44856da5ba0b1aa61403eb9fddd272156503
- https://git.kernel.org/stable/c/b70ff391deeec35cdd8a05f5f63f5fe28bc4f225
- https://git.kernel.org/stable/c/1c743127cc54b112b155f434756bd4b5fa565a99
- https://git.kernel.org/stable/c/39509d76a9a3d02f379d52cb4b1449469c56c0e0
- https://git.kernel.org/stable/c/7b6f44856da5ba0b1aa61403eb9fddd272156503
- https://git.kernel.org/stable/c/b70ff391deeec35cdd8a05f5f63f5fe28bc4f225
Package kernel-image-std-def updated to version 5.10.85-alt1 for branch sisyphus in task 291961.
Closed vulnerabilities
BDU:2024-04566
Уязвимость функции pch_can_rx_normal() драйвера Controller Area Network (CAN) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04567
Уязвимость функции ems_pcmcia_add_card() драйвера устройств Philips/NXP SJA1000 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10531
Уязвимость компонентов IB/hfi1 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2024-10574
Уязвимость компонента seg6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10575
Уязвимость компонента devlink ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2024-10576
Уязвимость компонента fq_pie ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10577
Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10580
Уязвимость компонента oss ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10582
Уязвимость компонента nfsd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10583
Уязвимость компонента nfsd ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2024-10584
Уязвимость компонента aio ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10586
Уязвимость компонента pm80xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10587
Уязвимость компонента AsoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-05
BDU:2024-10590
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10591
Уязвимость компонента mma8452 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10592
Уязвимость компонента kxcjk-1013 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04378
Уязвимость функции nfp_cpp_area_cache_add() модуля drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c - драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-04462
Уязвимость функции nfc_genl_dump_ses_done() модуля net/nfc/netlink.c подсистемы NFC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14241
Уязвимость функции bigben_worker() модуля drivers/hid/hid-bigbenff.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-01-06
CVE-2021-47499
In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the memory allocated by iio_triggered_buffer_setup() will not be freed, and cause memory leak as follows: unreferenced object 0xffff888009551400 (size 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ ....... backtrace: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013] Fix it by remove data->dready_trig condition in probe and remove.
- https://git.kernel.org/stable/c/14508fe13b1c578b3d2ba574f1d48b351975860c
- https://git.kernel.org/stable/c/3899700ddacbf7aaafadf44464fff3ff0d4e3307
- https://git.kernel.org/stable/c/60a55b9d91ba99eb8cf015bc46dc2de05e168a15
- https://git.kernel.org/stable/c/70c9774e180d151abaab358108e3510a8e615215
- https://git.kernel.org/stable/c/8c163a14277115ca962103910ab4cce55e862ffb
- https://git.kernel.org/stable/c/8c1d43f3a3fc7184c42d7398bdf59a2a2903e4fc
- https://git.kernel.org/stable/c/a3730f74159ad00a28960c0efe2a931fe6fe6b45
- https://git.kernel.org/stable/c/ee86d0bad80bdcd11a87e188a596727f41b62320
- https://git.kernel.org/stable/c/14508fe13b1c578b3d2ba574f1d48b351975860c
- https://git.kernel.org/stable/c/3899700ddacbf7aaafadf44464fff3ff0d4e3307
- https://git.kernel.org/stable/c/60a55b9d91ba99eb8cf015bc46dc2de05e168a15
- https://git.kernel.org/stable/c/70c9774e180d151abaab358108e3510a8e615215
- https://git.kernel.org/stable/c/8c163a14277115ca962103910ab4cce55e862ffb
- https://git.kernel.org/stable/c/8c1d43f3a3fc7184c42d7398bdf59a2a2903e4fc
- https://git.kernel.org/stable/c/a3730f74159ad00a28960c0efe2a931fe6fe6b45
- https://git.kernel.org/stable/c/ee86d0bad80bdcd11a87e188a596727f41b62320
Modified: 2025-01-06
CVE-2021-47500
In the Linux kernel, the following vulnerability has been resolved: iio: mma8452: Fix trigger reference couting The mma8452 driver directly assigns a trigger to the struct iio_dev. The IIO core when done using this trigger will call `iio_trigger_put()` to drop the reference count by 1. Without the matching `iio_trigger_get()` in the driver the reference count can reach 0 too early, the trigger gets freed while still in use and a use-after-free occurs. Fix this by getting a reference to the trigger before assigning it to the IIO device.
- https://git.kernel.org/stable/c/094d513b78b1714113bc016684b8142382e071ba
- https://git.kernel.org/stable/c/794c0898f6bf39a458655d5fb4af70ec43a5cfcb
- https://git.kernel.org/stable/c/acf0088ac073ca6e7f4cad6acac112177e08df5e
- https://git.kernel.org/stable/c/c43517071dfc9fce34f8f69dbb98a86017f6b739
- https://git.kernel.org/stable/c/cd0082235783f814241a1c9483fb89e405f4f892
- https://git.kernel.org/stable/c/db12d95085367de8b0223929d1332731024441f1
- https://git.kernel.org/stable/c/f5deab10ced368c807866283f8b79144c4823be8
- https://git.kernel.org/stable/c/fb75cc4740d81264cd5bcb0e17d961d018a8be96
- https://git.kernel.org/stable/c/094d513b78b1714113bc016684b8142382e071ba
- https://git.kernel.org/stable/c/794c0898f6bf39a458655d5fb4af70ec43a5cfcb
- https://git.kernel.org/stable/c/acf0088ac073ca6e7f4cad6acac112177e08df5e
- https://git.kernel.org/stable/c/c43517071dfc9fce34f8f69dbb98a86017f6b739
- https://git.kernel.org/stable/c/cd0082235783f814241a1c9483fb89e405f4f892
- https://git.kernel.org/stable/c/db12d95085367de8b0223929d1332731024441f1
- https://git.kernel.org/stable/c/f5deab10ced368c807866283f8b79144c4823be8
- https://git.kernel.org/stable/c/fb75cc4740d81264cd5bcb0e17d961d018a8be96
Modified: 2025-01-06
CVE-2021-47501
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc When trying to dump VFs VSI RX/TX descriptors using debugfs there was a crash due to NULL pointer dereference in i40e_dbg_dump_desc. Added a check to i40e_dbg_dump_desc that checks if VSI type is correct for dumping RX/TX descriptors.
- https://git.kernel.org/stable/c/16431e442db248ecd8aa9457cf0a656f1885f56e
- https://git.kernel.org/stable/c/23ec111bf3549aae37140330c31a16abfc172421
- https://git.kernel.org/stable/c/e5b7fb2198abc50058f1a29c395b004f76ab1c83
- https://git.kernel.org/stable/c/16431e442db248ecd8aa9457cf0a656f1885f56e
- https://git.kernel.org/stable/c/23ec111bf3549aae37140330c31a16abfc172421
- https://git.kernel.org/stable/c/e5b7fb2198abc50058f1a29c395b004f76ab1c83
Modified: 2025-09-29
CVE-2021-47502
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd934x: handle channel mappping list correctly Currently each channel is added as list to dai channel list, however there is danger of adding same channel to multiple dai channel list which endups corrupting the other list where its already added. This patch ensures that the channel is actually free before adding to the dai channel list and also ensures that the channel is on the list before deleting it. This check was missing previously, and we did not hit this issue as we were testing very simple usecases with sequence of amixer commands.
- https://git.kernel.org/stable/c/1089dac26c6b4b833323ae6c0ceab29fb30ede72
- https://git.kernel.org/stable/c/23ba28616d3063bd4c4953598ed5e439ca891101
- https://git.kernel.org/stable/c/339ffb5b56005582aacc860524d2d208604049d1
- https://git.kernel.org/stable/c/1089dac26c6b4b833323ae6c0ceab29fb30ede72
- https://git.kernel.org/stable/c/23ba28616d3063bd4c4953598ed5e439ca891101
- https://git.kernel.org/stable/c/339ffb5b56005582aacc860524d2d208604049d1
Modified: 2025-04-01
CVE-2021-47503
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Do not call scsi_remove_host() in pm8001_alloc() Calling scsi_remove_host() before scsi_add_host() results in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000108 RIP: 0010:device_del+0x63/0x440 Call Trace: device_unregister+0x17/0x60 scsi_remove_host+0xee/0x2a0 pm8001_pci_probe+0x6ef/0x1b90 [pm80xx] local_pci_probe+0x3f/0x90 We cannot call scsi_remove_host() in pm8001_alloc() because scsi_add_host() has not been called yet at that point in time. Function call tree: pm8001_pci_probe() | `- pm8001_pci_alloc() | | | `- pm8001_alloc() | | | `- scsi_remove_host() | `- scsi_add_host()
- https://git.kernel.org/stable/c/1e434d2687e8bc0b3cdc9dd093c0e9047c0b4add
- https://git.kernel.org/stable/c/653926205741add87a6cf452e21950eebc6ac10b
- https://git.kernel.org/stable/c/f8dccc1bdea7e21b5ec06c957aef8831c772661c
- https://git.kernel.org/stable/c/1e434d2687e8bc0b3cdc9dd093c0e9047c0b4add
- https://git.kernel.org/stable/c/653926205741add87a6cf452e21950eebc6ac10b
- https://git.kernel.org/stable/c/f8dccc1bdea7e21b5ec06c957aef8831c772661c
Modified: 2025-01-10
CVE-2021-47505
In the Linux kernel, the following vulnerability has been resolved:
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani
- https://git.kernel.org/stable/c/321fba81ec034f88aea4898993c1bf15605c023f
- https://git.kernel.org/stable/c/4105e6a128e8a98455dfc9e6dbb2ab0c33c4497f
- https://git.kernel.org/stable/c/47ffefd88abfffe8a040bcc1dd0554d4ea6f7689
- https://git.kernel.org/stable/c/50252e4b5e989ce64555c7aef7516bdefc2fea72
- https://git.kernel.org/stable/c/60d311f9e6381d779d7d53371f87285698ecee24
- https://git.kernel.org/stable/c/321fba81ec034f88aea4898993c1bf15605c023f
- https://git.kernel.org/stable/c/4105e6a128e8a98455dfc9e6dbb2ab0c33c4497f
- https://git.kernel.org/stable/c/47ffefd88abfffe8a040bcc1dd0554d4ea6f7689
- https://git.kernel.org/stable/c/50252e4b5e989ce64555c7aef7516bdefc2fea72
- https://git.kernel.org/stable/c/60d311f9e6381d779d7d53371f87285698ecee24
Modified: 2025-01-06
CVE-2021-47506
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix use-after-free due to delegation race A delegation break could arrive as soon as we've called vfs_setlease. A delegation break runs a callback which immediately (in nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru. If we then exit nfs4_set_delegation without hashing the delegation, it will be freed as soon as the callback is done with it, without ever being removed from del_recall_lru. Symptoms show up later as use-after-free or list corruption warnings, usually in the laundromat thread. I suspect aba2072f4523 "nfsd: grant read delegations to clients holding writes" made this bug easier to hit, but I looked as far back as v3.0 and it looks to me it already had the same problem. So I'm not sure where the bug was introduced; it may have been there from the beginning.
- https://git.kernel.org/stable/c/04a8d07f3d58308b92630045560799a3faa3ebce
- https://git.kernel.org/stable/c/148c816f10fd11df27ca6a9b3238cdd42fa72cd3
- https://git.kernel.org/stable/c/2becaa990b93cbd2928292c0b669d3abb6cf06d4
- https://git.kernel.org/stable/c/33645d3e22720cac1e4548f8fef57bf0649536ee
- https://git.kernel.org/stable/c/348714018139c39533c55661a0c7c990671396b4
- https://git.kernel.org/stable/c/548ec0805c399c65ed66c6641be467f717833ab5
- https://git.kernel.org/stable/c/e0759696de6851d7536efddfdd2dfed4c4df1f09
- https://git.kernel.org/stable/c/eeb0711801f5e19ef654371b627682aed3b11373
- https://git.kernel.org/stable/c/04a8d07f3d58308b92630045560799a3faa3ebce
- https://git.kernel.org/stable/c/148c816f10fd11df27ca6a9b3238cdd42fa72cd3
- https://git.kernel.org/stable/c/2becaa990b93cbd2928292c0b669d3abb6cf06d4
- https://git.kernel.org/stable/c/33645d3e22720cac1e4548f8fef57bf0649536ee
- https://git.kernel.org/stable/c/348714018139c39533c55661a0c7c990671396b4
- https://git.kernel.org/stable/c/548ec0805c399c65ed66c6641be467f717833ab5
- https://git.kernel.org/stable/c/e0759696de6851d7536efddfdd2dfed4c4df1f09
- https://git.kernel.org/stable/c/eeb0711801f5e19ef654371b627682aed3b11373
Modified: 2025-09-24
CVE-2021-47507
In the Linux kernel, the following vulnerability has been resolved: nfsd: Fix nsfd startup race (again) Commit bd5ae9288d64 ("nfsd: register pernet ops last, unregister first") has re-opened rpc_pipefs_event() race against nfsd_net_id registration (register_pernet_subsys()) which has been fixed by commit bb7ffbf29e76 ("nfsd: fix nsfd startup race triggering BUG_ON"). Restore the order of register_pernet_subsys() vs register_cld_notifier(). Add WARN_ON() to prevent a future regression. Crash info: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000012 CPU: 8 PID: 345 Comm: mount Not tainted 5.4.144-... #1 pc : rpc_pipefs_event+0x54/0x120 [nfsd] lr : rpc_pipefs_event+0x48/0x120 [nfsd] Call trace: rpc_pipefs_event+0x54/0x120 [nfsd] blocking_notifier_call_chain rpc_fill_super get_tree_keyed rpc_fs_get_tree vfs_get_tree do_mount ksys_mount __arm64_sys_mount el0_svc_handler el0_svc
- https://git.kernel.org/stable/c/8bf902fee5893cfc2f04a698abab47629699ae9a
- https://git.kernel.org/stable/c/b10252c7ae9c9d7c90552f88b544a44ee773af64
- https://git.kernel.org/stable/c/c520943a00ad5015704969ad3304c956bcd49d25
- https://git.kernel.org/stable/c/f5734b1714ca355703e9ea8fb61d04beff1790b9
- https://git.kernel.org/stable/c/8bf902fee5893cfc2f04a698abab47629699ae9a
- https://git.kernel.org/stable/c/b10252c7ae9c9d7c90552f88b544a44ee773af64
- https://git.kernel.org/stable/c/c520943a00ad5015704969ad3304c956bcd49d25
- https://git.kernel.org/stable/c/f5734b1714ca355703e9ea8fb61d04beff1790b9
Modified: 2025-09-29
CVE-2021-47509
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Limit the period size to 16MB Set the practical limit to the period size (the fragment shift in OSS) instead of a full 31bit; a too large value could lead to the exhaust of memory as we allocate temporary buffers of the period size, too. As of this patch, we set to 16MB limit, which should cover all use cases.
- https://git.kernel.org/stable/c/2e54cf6794bf82a54aaefc78da13819aea9cd28a
- https://git.kernel.org/stable/c/35a3e511032146941085f87dd9fb5b82ea5c00a2
- https://git.kernel.org/stable/c/76f19e4cbb548e28547f8c328aa0bfb3a10222d3
- https://git.kernel.org/stable/c/8839c8c0f77ab8fc0463f4ab8b37fca3f70677c2
- https://git.kernel.org/stable/c/ad45babf7886e7a212ee1d5eda9ef49f696db43c
- https://git.kernel.org/stable/c/b02a41eebcc36d4f07196780f2e165ca2c499257
- https://git.kernel.org/stable/c/be55f306396cd62c6889286a7194fd8b53363aeb
- https://git.kernel.org/stable/c/d1bb703ad050de9095f10b2d3416c32921ac6bcc
- https://git.kernel.org/stable/c/2e54cf6794bf82a54aaefc78da13819aea9cd28a
- https://git.kernel.org/stable/c/35a3e511032146941085f87dd9fb5b82ea5c00a2
- https://git.kernel.org/stable/c/76f19e4cbb548e28547f8c328aa0bfb3a10222d3
- https://git.kernel.org/stable/c/8839c8c0f77ab8fc0463f4ab8b37fca3f70677c2
- https://git.kernel.org/stable/c/ad45babf7886e7a212ee1d5eda9ef49f696db43c
- https://git.kernel.org/stable/c/b02a41eebcc36d4f07196780f2e165ca2c499257
- https://git.kernel.org/stable/c/be55f306396cd62c6889286a7194fd8b53363aeb
- https://git.kernel.org/stable/c/d1bb703ad050de9095f10b2d3416c32921ac6bcc
Modified: 2025-09-29
CVE-2021-47511
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix negative period/buffer sizes The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers. This patch changes the code to handle with ssize_t and adds the proper error checks appropriately.
- https://git.kernel.org/stable/c/00a860678098fcd9fa8db2b5fb9d2ddf4776d4cc
- https://git.kernel.org/stable/c/02b2b691b77cd7b951fa7b6c9d44d4e472cdc823
- https://git.kernel.org/stable/c/502e1146873d870f87da3b8f93d6bf2de5f38d0c
- https://git.kernel.org/stable/c/8af815ab052eaf74addbbfb556d63ce2137c0e1b
- https://git.kernel.org/stable/c/9d2479c960875ca1239bcb899f386970c13d9cfe
- https://git.kernel.org/stable/c/be8869d388593e57223ad39297c8e54be632f2f2
- https://git.kernel.org/stable/c/f12c8a7515f641885677960af450082569a87243
- https://git.kernel.org/stable/c/f96c0959c1ee92adc911c10d6ec209af50105049
- https://git.kernel.org/stable/c/00a860678098fcd9fa8db2b5fb9d2ddf4776d4cc
- https://git.kernel.org/stable/c/02b2b691b77cd7b951fa7b6c9d44d4e472cdc823
- https://git.kernel.org/stable/c/502e1146873d870f87da3b8f93d6bf2de5f38d0c
- https://git.kernel.org/stable/c/8af815ab052eaf74addbbfb556d63ce2137c0e1b
- https://git.kernel.org/stable/c/9d2479c960875ca1239bcb899f386970c13d9cfe
- https://git.kernel.org/stable/c/be8869d388593e57223ad39297c8e54be632f2f2
- https://git.kernel.org/stable/c/f12c8a7515f641885677960af450082569a87243
- https://git.kernel.org/stable/c/f96c0959c1ee92adc911c10d6ec209af50105049
Modified: 2025-01-06
CVE-2021-47512
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq_pie: prevent dismantle issue
For some reason, fq_pie_destroy() did not copy
working code from pie_destroy() and other qdiscs,
thus causing elusive bug.
Before calling del_timer_sync(&q->adapt_timer),
we need to ensure timer will not rearm itself.
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579
(t=10501 jiffies g=13085 q=3989)
NMI backtrace for cpu 0
CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
- https://git.kernel.org/stable/c/2a51edaf5cc563574878b93d7ef3d5955dda7030
- https://git.kernel.org/stable/c/61c2402665f1e10c5742033fce18392e369931d7
- https://git.kernel.org/stable/c/d86216dfda7c98375f809e26a30bfdaaba21d46e
- https://git.kernel.org/stable/c/2a51edaf5cc563574878b93d7ef3d5955dda7030
- https://git.kernel.org/stable/c/61c2402665f1e10c5742033fce18392e369931d7
- https://git.kernel.org/stable/c/d86216dfda7c98375f809e26a30bfdaaba21d46e
Modified: 2025-01-06
CVE-2021-47514
In the Linux kernel, the following vulnerability has been resolved: devlink: fix netns refcount leak in devlink_nl_cmd_reload() While preparing my patch series adding netns refcount tracking, I spotted bugs in devlink_nl_cmd_reload() Some error paths forgot to release a refcount on a netns. To fix this, we can reduce the scope of get_net()/put_net() section around the call to devlink_reload().
- https://git.kernel.org/stable/c/4b7e90672af8e0c78205db006f1b0a20ebd07f5f
- https://git.kernel.org/stable/c/4dbb0dad8e63fcd0b5a117c2861d2abe7ff5f186
- https://git.kernel.org/stable/c/fe30b70ca84da9c4aca85c03ad86e7a9b89c5ded
- https://git.kernel.org/stable/c/4b7e90672af8e0c78205db006f1b0a20ebd07f5f
- https://git.kernel.org/stable/c/4dbb0dad8e63fcd0b5a117c2861d2abe7ff5f186
- https://git.kernel.org/stable/c/fe30b70ca84da9c4aca85c03ad86e7a9b89c5ded
Modified: 2025-09-24
CVE-2021-47515
In the Linux kernel, the following vulnerability has been resolved: seg6: fix the iif in the IPv6 socket control block When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif; If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29). Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero). As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied. To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again.
- https://git.kernel.org/stable/c/6431e71093f3da586a00c6d931481ffb0dc2db0e
- https://git.kernel.org/stable/c/666521b3852d2b2f52d570f9122b1e4b50d96831
- https://git.kernel.org/stable/c/98adb2bbfa407c9290bda299d4c6f7a1c4ebd5e1
- https://git.kernel.org/stable/c/ae68d93354e5bf5191ee673982251864ea24dd5c
- https://git.kernel.org/stable/c/b16d412e5f79734033df04e97d7ea2f50a8e9fe3
- https://git.kernel.org/stable/c/ef8804e47c0a44ae106ead1740408af5ea6c6ee9
- https://git.kernel.org/stable/c/6431e71093f3da586a00c6d931481ffb0dc2db0e
- https://git.kernel.org/stable/c/666521b3852d2b2f52d570f9122b1e4b50d96831
- https://git.kernel.org/stable/c/98adb2bbfa407c9290bda299d4c6f7a1c4ebd5e1
- https://git.kernel.org/stable/c/ae68d93354e5bf5191ee673982251864ea24dd5c
- https://git.kernel.org/stable/c/b16d412e5f79734033df04e97d7ea2f50a8e9fe3
- https://git.kernel.org/stable/c/ef8804e47c0a44ae106ead1740408af5ea6c6ee9
Modified: 2024-11-21
CVE-2021-47516
In the Linux kernel, the following vulnerability has been resolved: nfp: Fix memory leak in nfp_cpp_area_cache_add() In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak. We can fix it by freeing the CPP area when the cache is allocated failed (#2). 792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache *cache; 795 struct nfp_cpp_area *area; 800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes 802 if (!area) 803 return -ENOMEM; 805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free 817 return 0; 818 }
- https://git.kernel.org/stable/c/2e0e072e62fdaf7816220af08e05c020f0fcb77a
- https://git.kernel.org/stable/c/3e93abcdcec0436fbf0b6a88ae806902426895a2
- https://git.kernel.org/stable/c/484069b5de9d223cc1c64c6f80389a99cfef51f1
- https://git.kernel.org/stable/c/c56c96303e9289cc34716b1179597b6f470833de
- https://git.kernel.org/stable/c/eb51f639ef3fd5498b7def290ed8681b6aadd9a7
- https://git.kernel.org/stable/c/f707820c09239d6f67699d9b2ff57863cc7905b0
- https://git.kernel.org/stable/c/2e0e072e62fdaf7816220af08e05c020f0fcb77a
- https://git.kernel.org/stable/c/3e93abcdcec0436fbf0b6a88ae806902426895a2
- https://git.kernel.org/stable/c/484069b5de9d223cc1c64c6f80389a99cfef51f1
- https://git.kernel.org/stable/c/c56c96303e9289cc34716b1179597b6f470833de
- https://git.kernel.org/stable/c/eb51f639ef3fd5498b7def290ed8681b6aadd9a7
- https://git.kernel.org/stable/c/f707820c09239d6f67699d9b2ff57863cc7905b0
Modified: 2024-11-21
CVE-2021-47518
In the Linux kernel, the following vulnerability has been resolved: nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done The done() netlink callback nfc_genl_dump_ses_done() should check if received argument is non-NULL, because its allocation could fail earlier in dumpit() (nfc_genl_dump_ses()).
- https://git.kernel.org/stable/c/3b861a40325eac9c4c13b6c53874ad90617e944d
- https://git.kernel.org/stable/c/48fcd08fdbe05e35b650a252ec2a2d96057a1c7a
- https://git.kernel.org/stable/c/4cd8371a234d051f9c9557fcbb1f8c523b1c0d10
- https://git.kernel.org/stable/c/69bb79a8f5bb9f436b6f1434ca9742591b7bbe18
- https://git.kernel.org/stable/c/811a7576747760bcaf60502f096d1e6e91d566fa
- https://git.kernel.org/stable/c/83ea620a1be840bf05089a5061fb8323ca42f38c
- https://git.kernel.org/stable/c/87cdb8789c38e44ae5454aafe277997c950d00ed
- https://git.kernel.org/stable/c/fae9705d281091254d4a81fa2da9d22346097dca
- https://git.kernel.org/stable/c/3b861a40325eac9c4c13b6c53874ad90617e944d
- https://git.kernel.org/stable/c/48fcd08fdbe05e35b650a252ec2a2d96057a1c7a
- https://git.kernel.org/stable/c/4cd8371a234d051f9c9557fcbb1f8c523b1c0d10
- https://git.kernel.org/stable/c/69bb79a8f5bb9f436b6f1434ca9742591b7bbe18
- https://git.kernel.org/stable/c/811a7576747760bcaf60502f096d1e6e91d566fa
- https://git.kernel.org/stable/c/83ea620a1be840bf05089a5061fb8323ca42f38c
- https://git.kernel.org/stable/c/87cdb8789c38e44ae5454aafe277997c950d00ed
- https://git.kernel.org/stable/c/fae9705d281091254d4a81fa2da9d22346097dca
Modified: 2024-11-21
CVE-2021-47520
In the Linux kernel, the following vulnerability has been resolved: can: pch_can: pch_can_rx_normal: fix use after free After calling netif_receive_skb(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is dereferenced just after the call netif_receive_skb(skb). Reordering the lines solves the issue.
- https://git.kernel.org/stable/c/3a3c46e2eff0577454860a203be1a8295f4acb76
- https://git.kernel.org/stable/c/3e193ef4e0a3f5bf92ede83ef214cb09d01b00aa
- https://git.kernel.org/stable/c/6c73fc931658d8cbc8a1714b326cb31eb71d16a7
- https://git.kernel.org/stable/c/703dde112021c93d6e89443c070e7dbd4dea612e
- https://git.kernel.org/stable/c/94cddf1e9227a171b27292509d59691819c458db
- https://git.kernel.org/stable/c/abb4eff3dcd2e583060082a18a8dbf31f02689d4
- https://git.kernel.org/stable/c/affbad02bf80380a7403885b9fe4a1587d1bb4f3
- https://git.kernel.org/stable/c/bafe343a885c70dddf358379cf0b2a1c07355d8d
- https://git.kernel.org/stable/c/3a3c46e2eff0577454860a203be1a8295f4acb76
- https://git.kernel.org/stable/c/3e193ef4e0a3f5bf92ede83ef214cb09d01b00aa
- https://git.kernel.org/stable/c/6c73fc931658d8cbc8a1714b326cb31eb71d16a7
- https://git.kernel.org/stable/c/703dde112021c93d6e89443c070e7dbd4dea612e
- https://git.kernel.org/stable/c/94cddf1e9227a171b27292509d59691819c458db
- https://git.kernel.org/stable/c/abb4eff3dcd2e583060082a18a8dbf31f02689d4
- https://git.kernel.org/stable/c/affbad02bf80380a7403885b9fe4a1587d1bb4f3
- https://git.kernel.org/stable/c/bafe343a885c70dddf358379cf0b2a1c07355d8d
Modified: 2024-11-21
CVE-2021-47521
In the Linux kernel, the following vulnerability has been resolved: can: sja1000: fix use after free in ems_pcmcia_add_card() If the last channel is not available then "dev" is freed. Fortunately, we can just use "pdev->irq" instead. Also we should check if at least one channel was set up.
- https://git.kernel.org/stable/c/1a295fea90e1acbe80c6d4940f5ff856edcd6bec
- https://git.kernel.org/stable/c/1dd5b819f7e406dc15bbc7670596ff25261aaa2a
- https://git.kernel.org/stable/c/3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45
- https://git.kernel.org/stable/c/474f9a8534f5f89841240a7e978bafd6e1e039ce
- https://git.kernel.org/stable/c/923f4dc5df679f678e121c20bf2fd70f7bf3e288
- https://git.kernel.org/stable/c/c8718026ba287168ff9ad0ccc4f9a413062cba36
- https://git.kernel.org/stable/c/cbd86110546f7f730a1f5d7de56c944a336c15c4
- https://git.kernel.org/stable/c/ccf070183e4655824936c0f96c4a2bcca93419aa
- https://git.kernel.org/stable/c/1a295fea90e1acbe80c6d4940f5ff856edcd6bec
- https://git.kernel.org/stable/c/1dd5b819f7e406dc15bbc7670596ff25261aaa2a
- https://git.kernel.org/stable/c/3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45
- https://git.kernel.org/stable/c/474f9a8534f5f89841240a7e978bafd6e1e039ce
- https://git.kernel.org/stable/c/923f4dc5df679f678e121c20bf2fd70f7bf3e288
- https://git.kernel.org/stable/c/c8718026ba287168ff9ad0ccc4f9a413062cba36
- https://git.kernel.org/stable/c/cbd86110546f7f730a1f5d7de56c944a336c15c4
- https://git.kernel.org/stable/c/ccf070183e4655824936c0f96c4a2bcca93419aa
Modified: 2024-11-21
CVE-2021-47522
In the Linux kernel, the following vulnerability has been resolved: HID: bigbenff: prevent null pointer dereference When emulating the device through uhid, there is a chance we don't have output reports and so report_field is null.
- https://git.kernel.org/stable/c/58f15f5ae7786c824868f3a7e093859b74669ce7
- https://git.kernel.org/stable/c/6272b17001e6fdcf7b4a16206287010a1523fa6e
- https://git.kernel.org/stable/c/8e0ceff632f48175ec7fb4706129c55ca8a7c7bd
- https://git.kernel.org/stable/c/918aa1ef104d286d16b9e7ef139a463ac7a296f0
- https://git.kernel.org/stable/c/58f15f5ae7786c824868f3a7e093859b74669ce7
- https://git.kernel.org/stable/c/6272b17001e6fdcf7b4a16206287010a1523fa6e
- https://git.kernel.org/stable/c/8e0ceff632f48175ec7fb4706129c55ca8a7c7bd
- https://git.kernel.org/stable/c/918aa1ef104d286d16b9e7ef139a463ac7a296f0
Modified: 2025-09-24
CVE-2021-47523
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddr This buffer is currently allocated in hfi1_init(): if (reinit) ret = init_after_reset(dd); else ret = loadtime_init(dd); if (ret) goto done; /* allocate dummy tail memory for all receive contexts */ dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64), &dd->rcvhdrtail_dummy_dma, GFP_KERNEL); if (!dd->rcvhdrtail_dummy_kvaddr) { dd_dev_err(dd, "cannot allocate dummy tail memory\n"); ret = -ENOMEM; goto done; } The reinit triggered path will overwrite the old allocation and leak it. Fix by moving the allocation to hfi1_alloc_devdata() and the deallocation to hfi1_free_devdata().
- https://git.kernel.org/stable/c/2c08271f4ed0e24633b3f81ceff61052b9d45efc
- https://git.kernel.org/stable/c/60a8b5a1611b4a26de4839ab9c1fc2a9cf3e17c1
- https://git.kernel.org/stable/c/834d0fb978643eaf09da425de197cc16a7c2761b
- https://git.kernel.org/stable/c/2c08271f4ed0e24633b3f81ceff61052b9d45efc
- https://git.kernel.org/stable/c/60a8b5a1611b4a26de4839ab9c1fc2a9cf3e17c1
- https://git.kernel.org/stable/c/834d0fb978643eaf09da425de197cc16a7c2761b
