ALT-BU-2023-7846-25
Branch p10 update bulletin.
Closed vulnerabilities
Modified: 2025-11-19
BDU:2023-00665
Уязвимость функции GENERAL_NAME_cmp библиотеки OpenSSL, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-04
CVE-2023-0286
There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.
- https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.6.2-relnotes.txt
- https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x509.patch.sig
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2c6c9d439b484e1ba9830d8454a34fa4f80fdfe9
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2f7530077e0ef79d98718138716bc51ca0cad658
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=fd2af07dc083a350c959147097003a14a5e8ac4d
- https://security.gentoo.org/glsa/202402-08
- https://www.openssl.org/news/secadv/20230207.txt
- https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.6.2-relnotes.txt
- https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x509.patch.sig
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2c6c9d439b484e1ba9830d8454a34fa4f80fdfe9
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2f7530077e0ef79d98718138716bc51ca0cad658
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=fd2af07dc083a350c959147097003a14a5e8ac4d
- https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2023-0003
- https://security.gentoo.org/glsa/202402-08
- https://www.openssl.org/news/secadv/20230207.txt
Modified: 2025-11-05
GHSA-x4qr-2fvf-3mr5
Vulnerable OpenSSL included in cryptography wheels
- https://github.com/pyca/cryptography/security/advisories/GHSA-x4qr-2fvf-3mr5
- https://nvd.nist.gov/vuln/detail/CVE-2023-0286
- https://access.redhat.com/security/cve/cve-2023-0286
- https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.6.2-relnotes.txt
- https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x509.patch.sig
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2c6c9d439b484e1ba9830d8454a34fa4f80fdfe9
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2f7530077e0ef79d98718138716bc51ca0cad658
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=fd2af07dc083a350c959147097003a14a5e8ac4d
- https://github.com/pyca/cryptography
- https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2023-0003
- https://rustsec.org/advisories/RUSTSEC-2023-0006.html
- https://security.gentoo.org/glsa/202402-08
- https://www.openssl.org/news/secadv/20230207.txt
Closed vulnerabilities
Modified: 2026-03-04
BDU:2023-07841
Уязвимость компонента WebAudio браузеров Google Chrome и Microsoft Edge, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-04
BDU:2023-08091
Уязвимость компонента Navigation браузеров Google Chrome и Microsoft Edge, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-04
BDU:2023-08092
Уязвимость компонента Garbage Collector («Сборщик мусора») браузеров Google Chrome и Microsoft Edge, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-21
CVE-2023-5996
Use after free in WebAudio in Google Chrome prior to 119.0.6045.123 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
- https://chromereleases.googleblog.com/2023/11/stable-channel-update-for-desktop.html
- https://crbug.com/1497859
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2MHLJRFWZNY6BFOW25Q4FEESVWZKS4C2/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PHWLT3M2AQDFD7RNAM3NJMYUC5KHMO5V/
- https://security.gentoo.org/glsa/202311-11
- https://security.gentoo.org/glsa/202312-07
- https://security.gentoo.org/glsa/202401-34
- https://www.debian.org/security/2023/dsa-5551
- https://chromereleases.googleblog.com/2023/11/stable-channel-update-for-desktop.html
- https://crbug.com/1497859
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2MHLJRFWZNY6BFOW25Q4FEESVWZKS4C2/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PHWLT3M2AQDFD7RNAM3NJMYUC5KHMO5V/
- https://security.gentoo.org/glsa/202311-11
- https://security.gentoo.org/glsa/202312-07
- https://security.gentoo.org/glsa/202401-34
- https://www.debian.org/security/2023/dsa-5551
Modified: 2024-11-21
CVE-2023-5997
Use after free in Garbage Collection in Google Chrome prior to 119.0.6045.159 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
- https://chromereleases.googleblog.com/2023/11/stable-channel-update-for-desktop_14.html
- https://crbug.com/1497997
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JHUI5HW7QXT3U74MJMTLUMF5REDO5HD5/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MN3JQGEC4EFQP3WTI33YBD3CLC3I7P4X/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XWHRLW3GDNFBFSBHDD4QOPUPX7ORTUEC/
- https://security.gentoo.org/glsa/202311-11
- https://security.gentoo.org/glsa/202312-07
- https://security.gentoo.org/glsa/202401-34
- https://www.debian.org/security/2023/dsa-5556
- https://chromereleases.googleblog.com/2023/11/stable-channel-update-for-desktop_14.html
- https://crbug.com/1497997
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JHUI5HW7QXT3U74MJMTLUMF5REDO5HD5/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MN3JQGEC4EFQP3WTI33YBD3CLC3I7P4X/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XWHRLW3GDNFBFSBHDD4QOPUPX7ORTUEC/
- https://security.gentoo.org/glsa/202311-11
- https://security.gentoo.org/glsa/202312-07
- https://security.gentoo.org/glsa/202401-34
- https://www.debian.org/security/2023/dsa-5556
Modified: 2024-11-21
CVE-2023-6112
Use after free in Navigation in Google Chrome prior to 119.0.6045.159 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
- http://packetstormsecurity.com/files/176721/Chrome-content-NavigationURLLoaderImpl-FallbackToNonInterceptedRequest-Heap-Use-After-Free.html
- https://chromereleases.googleblog.com/2023/11/stable-channel-update-for-desktop_14.html
- https://crbug.com/1499298
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JHUI5HW7QXT3U74MJMTLUMF5REDO5HD5/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MN3JQGEC4EFQP3WTI33YBD3CLC3I7P4X/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XWHRLW3GDNFBFSBHDD4QOPUPX7ORTUEC/
- https://security.gentoo.org/glsa/202311-11
- https://security.gentoo.org/glsa/202312-07
- https://security.gentoo.org/glsa/202401-34
- https://www.debian.org/security/2023/dsa-5556
- http://packetstormsecurity.com/files/176721/Chrome-content-NavigationURLLoaderImpl-FallbackToNonInterceptedRequest-Heap-Use-After-Free.html
- https://chromereleases.googleblog.com/2023/11/stable-channel-update-for-desktop_14.html
- https://crbug.com/1499298
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JHUI5HW7QXT3U74MJMTLUMF5REDO5HD5/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MN3JQGEC4EFQP3WTI33YBD3CLC3I7P4X/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XWHRLW3GDNFBFSBHDD4QOPUPX7ORTUEC/
- https://security.gentoo.org/glsa/202311-11
- https://security.gentoo.org/glsa/202312-07
- https://security.gentoo.org/glsa/202401-34
- https://www.debian.org/security/2023/dsa-5556
Closed vulnerabilities
Modified: 2024-04-01
BDU:2023-07551
Уязвимость программ системного администрирования Sudo-rs, связанная с недостаточной проверкой введенных пользователем командных аргументов, позволяющая нарушителю повысить свои привилегии путём создания специально сформированного имени пользователя
Modified: 2025-11-19
BDU:2024-01160
Уязвимость программы системного администрирования Sudo, связанная с недостатками процедуры аутентификации, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-21
CVE-2023-42456
Sudo-rs, a memory safe implementation of sudo and su, allows users to not have to enter authentication at every sudo attempt, but instead only requiring authentication every once in a while in every terminal or process group. Only once a configurable timeout has passed will the user have to re-authenticate themselves. Supporting this functionality is a set of session files (timestamps) for each user, stored in `/var/run/sudo-rs/ts`. These files are named according to the username from which the sudo attempt is made (the origin user). An issue was discovered in versions prior to 0.2.1 where usernames containing the `.` and `/` characters could result in the corruption of specific files on the filesystem. As usernames are generally not limited by the characters they can contain, a username appearing to be a relative path can be constructed. For example we could add a user to the system containing the username `../../../../bin/cp`. When logged in as a user with that name, that user could run `sudo -K` to clear their session record file. The session code then constructs the path to the session file by concatenating the username to the session file storage directory, resulting in a resolved path of `/bin/cp`. The code then clears that file, resulting in the `cp` binary effectively being removed from the system. An attacker needs to be able to login as a user with a constructed username. Given that such a username is unlikely to exist on an existing system, they will also need to be able to create the users with the constructed usernames. The issue is patched in version 0.2.1 of sudo-rs. Sudo-rs now uses the uid for the user instead of their username for determining the filename. Note that an upgrade to this version will result in existing session files being ignored and users will be forced to re-authenticate. It also fully eliminates any possibility of path traversal, given that uids are always integer values. The `sudo -K` and `sudo -k` commands can run, even if a user has no sudo access. As a workaround, make sure that one's system does not contain any users with a specially crafted username. While this is the case and while untrusted users do not have the ability to create arbitrary users on the system, one should not be able to exploit this issue.
- http://www.openwall.com/lists/oss-security/2023/11/02/1
- https://ferrous-systems.com/blog/sudo-rs-audit/
- https://github.com/memorysafety/sudo-rs/commit/bfdbda22968e3de43fa8246cab1681cfd5d5493d
- https://github.com/memorysafety/sudo-rs/security/advisories/GHSA-2r3c-m6v7-9354
- http://www.openwall.com/lists/oss-security/2023/11/02/1
- https://ferrous-systems.com/blog/sudo-rs-audit/
- https://github.com/memorysafety/sudo-rs/commit/bfdbda22968e3de43fa8246cab1681cfd5d5493d
- https://github.com/memorysafety/sudo-rs/security/advisories/GHSA-2r3c-m6v7-9354
Modified: 2025-11-04
CVE-2023-42465
Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.
- https://arxiv.org/abs/2309.02545
- https://github.com/sudo-project/sudo/commit/7873f8334c8d31031f8cfa83bd97ac6029309e4f
- https://github.com/sudo-project/sudo/releases/tag/SUDO_1_9_15
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/R4Q23NHCKCLFIHSNY6KJ27GM7FSCEVXM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/U6XMRUJCPII4MPWG43HTYR76DGLEYEFZ/
- https://security.gentoo.org/glsa/202401-29
- https://security.netapp.com/advisory/ntap-20240208-0002/
- https://www.openwall.com/lists/oss-security/2023/12/21/9
- https://www.sudo.ws/releases/changelog/
- http://www.openwall.com/lists/oss-security/2025/09/23/2
- http://www.openwall.com/lists/oss-security/2025/09/24/6
- https://arxiv.org/abs/2309.02545
- https://github.com/sudo-project/sudo/commit/7873f8334c8d31031f8cfa83bd97ac6029309e4f
- https://github.com/sudo-project/sudo/releases/tag/SUDO_1_9_15
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/R4Q23NHCKCLFIHSNY6KJ27GM7FSCEVXM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/U6XMRUJCPII4MPWG43HTYR76DGLEYEFZ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/R4Q23NHCKCLFIHSNY6KJ27GM7FSCEVXM/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U6XMRUJCPII4MPWG43HTYR76DGLEYEFZ/
- https://security.gentoo.org/glsa/202401-29
- https://security.netapp.com/advisory/ntap-20240208-0002/
- https://www.openwall.com/lists/oss-security/2023/12/21/9
- https://www.sudo.ws/releases/changelog/
Modified: 2025-05-13
GHSA-2r3c-m6v7-9354
sudo-rs Session File Relative Path Traversal vulnerability
- https://github.com/memorysafety/sudo-rs/security/advisories/GHSA-2r3c-m6v7-9354
- https://github.com/trifectatechfoundation/sudo-rs/security/advisories/GHSA-2r3c-m6v7-9354
- https://nvd.nist.gov/vuln/detail/CVE-2023-42456
- https://github.com/memorysafety/sudo-rs/commit/bfdbda22968e3de43fa8246cab1681cfd5d5493d
- https://ferrous-systems.com/blog/sudo-rs-audit
- https://github.com/advisories/GHSA-2r3c-m6v7-9354
- https://github.com/memorysafety/sudo-rs
- https://rustsec.org/advisories/RUSTSEC-2023-0069.html
- http://www.openwall.com/lists/oss-security/2023/11/02/1
Package kernel-image-rpi-def updated to version 5.15.92-alt2 for branch p10 in task 335377.
Closed vulnerabilities
Modified: 2025-01-29
BDU:2022-06272
Уязвимость функции cfg80211_update_notlisted_nontrans файла net/wireless/scan.c ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-01-29
BDU:2022-06273
Уязвимость функционала подсчета ссылок в режиме BSS (Basic Service Set) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-01-29
BDU:2022-06274
Уязвимость ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-06550
Уязвимость функции l2cap_conn_del() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-06564
Уязвимость функции l2cap_reassemble_sdu() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-06620
Уязвимость функции del_timer компонента drivers/isdn/mISDN/l1oip_core.c ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-07074
Уязвимость функций l2cap_connect и l2cap_le_connect_req (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-07218
Уязвимость функции l2cap_config_req (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2022-07336
Уязвимость функции __do_proc_dointvec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-06-07
BDU:2022-07505
Уязвимость драйвера беспроводной сети WILC1000 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-06-07
BDU:2022-07506
Уязвимость драйвера беспроводной сети WILC1000 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-07507
Уязвимость драйвера беспроводной сети WILC1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить уровень привилегий
Modified: 2024-06-07
BDU:2022-07508
Уязвимость драйвера беспроводной сети WILC1000 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2023-00061
Уязвимость драйвера GPU i915 ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2024-09-24
BDU:2023-00164
Уязвимость функции ksmbd_decode_ntlmssp_auth_blob модуля ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-00359
Уязвимость драйвера drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2023-00361
Уязвимость функций gru_set_context_option(), gru_fault() и gru_handle_user_call_os() драйвера SGI GRU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-09-30
BDU:2023-00380
Уязвимость драйвера drivers/net/wireless/rndis_wlan.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-30
BDU:2023-00382
Уязвимость компонента ALSA:pcm (звуковой подсистемы) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании и получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-24
BDU:2023-00383
Уязвимость компонентa netfilter ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации и повысить свои привилегии.
Modified: 2024-09-30
BDU:2023-00631
Уязвимость функции nilfs_new_inode компонента BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2023-00749
Уязвимость функции ib_prctl_set() ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
Modified: 2025-01-29
BDU:2023-00946
Уязвимость функции follow_page_pte файла mm/gup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-30
BDU:2023-00976
Уязвимость функции ntfs_attr_find() (fs/ntfs/attrib.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-01-09
BDU:2023-01112
Уязвимость функции ntfs_trim_fs() компонента fs/ntfs3/bitmap.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-01-09
BDU:2023-01122
Уязвимость функции run_unpack() компонента fs/ntfs3/run.c ядра операционных систем Linux, позволяющая нарушителю вызвать оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2023-01200
Уязвимость реализации протокола Upper Level Protocol (ULP) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии, выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-01572
Уязвимость функции stat() подсистемы OverlayFS ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-03-19
BDU:2023-01746
Уязвимость функции ntfs_read_mft() в модуле fs/ntfs3/inode.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-08-14
BDU:2023-01795
Уязвимость сервера NFS (Network File System) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-01-09
BDU:2023-02604
Уязвимость функции rxrpc_unbundle_conn() ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2026-01-20
BDU:2023-04465
Уязвимость функции tun_napi_alloc_frags() в модуле drivers/net/tun.c драйвера TUN/TAP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2024-10-04
BDU:2024-06622
Уязвимость компонента hci_qca ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-04
BDU:2024-06623
Уязвимость компонента efi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-04
BDU:2024-06624
Уязвимость компонента sched/core ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-12
BDU:2024-06855
Уязвимость функции ieee80211_tx_ba_session_handle_start() в компоненте mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06856
Уязвимость компонента idxd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07447
Уязвимость компонентов btrfs ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07448
Уязвимость функции axi_chan_handle_err () ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07449
Уязвимость функций xhci_free_dev() и xhci_kill_endpoint_urbs() компонентов xhci ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07450
Уязвимость компонентов nilfs2 ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07451
Уязвимость компонентов xhci ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07452
Уязвимость компонента io_uring ядра операционной системы Linux, связанная с неправильной блокировкой, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07453
Уязвимость компонента act_mpls ядра операционной системы Linux, связанная с неправильной проверкой входных данных, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-26
BDU:2024-07454
Уязвимость компонента nfc ядра операционной системы Linux, связанная с использованием памяти после освобождения, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07456
Уязвимость компонента iommu ядра операционной системы Linux, связанная с выходом операции за границы буфера в памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-18
BDU:2024-07587
Уязвимость компонента qcom-geni-serial ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность и доступность защищаемой информации
Modified: 2024-10-11
BDU:2024-07607
Уязвимость компонента f_ncm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07613
Уязвимость компонента gsmi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07617
Уязвимость компонента drm/virtio ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность, целостность и доступность
Modified: 2024-11-06
BDU:2024-07620
Уязвимость функции dp_aux_cmd_fifo_tx() компонента dp ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07626
Уязвимость компонента ixgbe ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07627
Уязвимость компонента da9211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07628
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-18
BDU:2024-07629
Уязвимость компонента fastrpc ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-18
BDU:2024-07630
Уязвимость компонента fastrpc ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-11
BDU:2024-07631
Уязвимость компонента tty ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07632
Уязвимость компонента gadgetfs ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2024-08163
Уязвимость компонента vivid ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-13
BDU:2024-09780
Уязвимость функции perf_pending_task() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-09781
Уязвимость функции ip6_fragment() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-13
BDU:2024-09782
Уязвимость функции hix5hd2_rx() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-13
BDU:2024-09783
Уязвимость функции hisi_femac_rx() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-19
BDU:2024-09786
Уязвимость функции ibmpex_register_bmc() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-13
BDU:2024-10087
Уязвимость функции qeth_l2_br2dev_worker() ядра операционной системы Linux на платформе s390, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10088
Уязвимость функции tun_detach() драйвера tun ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10089
Уязвимость функции hsr_deliver_master() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10090
Уязвимость функции tipc_crypto_rcv_complete() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10091
Уязвимость функции mlx5_eswitch_add_termtbl_rule() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10092
Уязвимость функции e100_xmit_prepare() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10099
Уязвимость функции memcg_write_event_control() подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-09
BDU:2025-01680
Уязвимость функции gup_pud_range() в модуле mm/gup.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01681
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01682
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01683
Уязвимость компонента HID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01684
Уязвимость компонента gpiolib ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-02-26
BDU:2025-01685
Уязвимость компонента mac802154 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01686
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01689
Уязвимость компонента octeontx2-pf ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-02-26
BDU:2025-01690
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-02-26
BDU:2025-01691
Уязвимость компонента rtc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01692
Уязвимость компонента AsoC ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-02-26
BDU:2025-01693
Уязвимость компонента igb ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2025-01694
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-26
BDU:2025-01695
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-26
BDU:2025-01696
Уязвимость компонента NFC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-09
BDU:2025-01697
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01698
Уязвимость компонентов gpio/rockchip ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01699
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01700
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-02-26
BDU:2025-01701
Уязвимость компонента ethernet ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-03-18
BDU:2025-01702
Уязвимость компонента udf ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-26
BDU:2025-01704
Уязвимость компонента io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01705
Уязвимость компонентов drm/shmem-helper ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01706
Уязвимость компонента can ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01707
Уязвимость компонента gpio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01708
Уязвимость компонента dpaa2-switch ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-03-18
BDU:2025-01709
Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01710
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-26
BDU:2025-01711
Уязвимость компонента af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01712
Уязвимость компонента xen-netfront ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01928
Уязвимость компонентов platform/surface ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01976
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01978
Уязвимость компонента iio ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-03-18
BDU:2025-01979
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01982
Уязвимость компонента libbpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-09
BDU:2025-01985
Уязвимость компонента iio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04347
Уязвимость функции efi_init() модуля arch/riscv/include/asm/efi.h на процессорах с архитектурой RISC-V ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2025-04372
Уязвимость функции padata_reorder() модуля kernel/padata.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04428
Уязвимость функции sctp_stream_outq_migrate() в модуле net/sctp/stream.c реализации протокола SCTP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04435
Уязвимость функции iavf_init_module() модуля drivers/net/ethernet/intel/iavf/iavf_main.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
BDU:2025-04436
Уязвимость функции p9_socket_open() модуля net/9p/trans_fd.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04437
Уязвимость функции adjust_tjmax() модуля drivers/hwmon/coretemp.c - драйвера мониторинга оборудования ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-04438
Уязвимость функции snd_soc_put_volsw_sx() модуля sound/soc/soc-ops.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06025
Уязвимость функции nft_payload() модуля net/netfilter /nft_payload.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06232
Уязвимость функции ip_metrics_convert() компонента ipv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06234
Уязвимость функции bpf_send_signal_common() компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06260
Уязвимость функции fib_metrics_match() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06265
Уязвимость функции init_ISA_irqs() и make_8259A_irq() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06268
Уязвимость функции simulation_jalr() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06269
Уязвимость функции skb_segment_list() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06287
Уязвимость компонентов perf/x86/amd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06288
Уязвимость компонента i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06289
Уязвимость компонента w1 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06296
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06297
Уязвимость компонента zmap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06298
Уязвимость компонента property.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06299
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06301
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06303
Уязвимость компонентов EDAC/highbank ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06304
Уязвимость компонента reset ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06308
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06330
Уязвимость функции create_hist_field() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06331
Уязвимость функции dwmac5_handle_dma_err() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06332
Уязвимость функции local_cleanup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06333
Уязвимость функции enetc_tx_onestep_tstamp() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06336
Уязвимость функции init_events() и early_trace_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06339
Уязвимость функции check_stack_write_fixed_off() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06340
Уязвимость функции EXPORT_SYMBOL() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06346
Уязвимость функции taprio_reset() и taprio_destroy() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06348
Уязвимость функции EXPORT_SYMBOL() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06350
Уязвимость функции l2tp_xmit_core(), l2tp_tunnel_create() и l2tp_tunnel_register() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06351
Уязвимость функции betopff_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06353
Уязвимость функции rfcomm_sock_connect() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании1
Modified: 2026-02-17
BDU:2025-06357
Уязвимость функции pt_core_execute_cmd() и pt_core_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06359
Уязвимость функции smbd_destroy() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06360
Уязвимость функции dump_syn_reg(), llcc_ecc_irq_handler() и qcom_llcc_edac_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06362
Уязвимость функции validate_nla() и __nla_validate_parse() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-07469
Уязвимость функции retract_page_tables() модуля mm/khugepaged.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-07471
Уязвимость функции ieee80211_get_rate_duration() модуля net/mac80211/airtime.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-07472
Уязвимость функции cfg80211_gen_new_ie() модуля net/wireless/scan.c поддержки беспроводной связи ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-07497
Уязвимость функции fib_nh_match() модуля net/ipv4/fib_semantics.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07502
Уязвимость функции get_overflow_stack() модуля arch/riscv/kernel/traps.c подсистемы управления модулями платформы с архитектурой RISC-V ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-07504
Уязвимость функции dyn_event_release() модуля kernel/trace/trace_dynevent.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-10252
Уязвимость функции bpf_prog_test_run_skb() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-10253
Уязвимость функции snd_soc_exit() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-10254
Уязвимость функции udf_find_entry() ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10255
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после ее освобождения, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-12487
Уязвимость ядра операционной системы Linux, связанная с некорректной проверкой количества данных на входе, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12794
Уязвимость функции rockchip_clk_register_pll() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2025-12795
Уязвимость функции chameleon_parse_gdd() в модуле drivers/mcb/mcb-parse.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-12796
Уязвимость функции mxm_wmi_call_mx() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12801
Уязвимость функции radeon_atrm_get_bios() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12804
Уязвимость модуля fs/nilfs2/segment.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2025-12807
Уязвимость функции send_args() в модуле fs/dlm/lock.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-12808
Уязвимость функции hpd_rx_irq_create_workqueue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12809
Уязвимость модуля drivers/usb/gadget/function/f_hid.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12810
Уязвимость функции ext4_fc_record_regions() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12811
Уязвимость функции get_default_font() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12812
Уязвимость функции rtw_init_cmd_priv() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12813
Уязвимость функции arm_smmu_pmu_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12814
Уязвимость модуля drivers/media/platform/chips-media/coda-bit.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14266
Уязвимость функции dpcm_be_reparent() модуля sound/soc/soc-pcm.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14267
Уязвимость функции snd_seq_expand_var_event() модуля sound/core/seq/seq_memory.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14268
Уязвимость функции raydium_i2c_send() модуля drivers/input/touchscreen/raydium_i2c_ts.c драйвера поддержки сенсорного экрана ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14270
Уязвимость функции has_external_pci() модуля drivers/iommu/intel/iommu.c драйвера поддержки IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14271
Уязвимость функции dmar_dev_scope_init() модуля drivers/iommu/dmar.c драйвера поддержки IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14272
Уязвимость функции nilfs_dat_commit_free() модуля fs/nilfs2/dat.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14275
Уязвимость функции coretemp_remove_core() модуля drivers/hwmon/coretemp.c драйвера мониторинга оборудования ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14276
Уязвимость функции fwnode_mdiobus_register_phy() модуля drivers/net/mdio/fwnode_mdio.c драйвера сетевых устройств шины MDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14277
Уязвимость функции nixge_hw_dma_bd_release() модуля drivers/net/ethernet/ni/nixge.c драйвера поддержки сетевых адаптеров National Instruments ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14278
Уязвимость функции phy_attach_direct() модуля drivers/net/phy/phy_device.c драйвера поддержки сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14279
Уязвимость функции m_can_pci_probe() модуля drivers/net/can/m_can/m_can_pci.c драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14280
Уязвимость функции ixgbevf_init_module() модуля drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14570
Уязвимость функции tpm_pm_suspend() модуля drivers/char/tpm/tpm-interface.c драйвера поддержки алфавитно-цифровых устройств с TPM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15380
Уязвимость функции nvme_ns_remove() модуля drivers/nvme/host/core.c - драйвера поддержки NVME ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01283
Уязвимость функции btrfs_quota_enable() модуля fs/btrfs/qgroup.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01285
Уязвимость функции kernfs_remove_by_name_ns() модуля fs/kernfs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01289
Уязвимость функции si470x_usb_driver_probe() модуля drivers/media/radio/si470x/radio-si470x-usb.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01290
Уязвимость функции brcmf_fw_alloc_request() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01343
Уязвимость функции l2cap_connect_create_rsp() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01507
Уязвимость функции ntfs_read_inode_mount() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01509
Уязвимость функций nilfs_relax_pressure_in_lock() и nilfs_construct_segment() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01541
Уязвимость функции hci_sync_conn_complete_evt() модуля net/bluetooth/hci_event.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01631
Уязвимость функции nouveau_gem_prime_import_sg_table() модуля drivers/gpu/drm/nouveau/nouveau_prime.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Nouveau (NVIDIA) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02173
Уязвимость функции nfsd4_close_open_stateid() в модуле fs/nfsd/nfs4state.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02174
Уязвимость функции igb_alloc_q_vector() в модуле drivers/net/ethernet/intel/igb/igb_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02176
Уязвимость драйвера dvb-core ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02177
Уязвимость функции sata_pmp_init_links() в модуле drivers/ata/libata-pmp.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02178
Уязвимость функции fpdt_process_subtable() в модуле drivers/acpi/acpi_fpdt.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02179
Уязвимость функции jbd2_fc_wait_bufs() в модуле fs/jbd2/journal.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02181
Уязвимость функции brcmf_netdev_start_xmit() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02182
Уязвимость функции nfsd_proc_read() в модуле fs/nfsd/nfsproc.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02185
Уязвимость функции acpi_ds_call_control_method() в модуле drivers/acpi/acpica/dsmethod.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02258
Уязвимость функции ext4_fc_replay_scan() в модуле fs/ext4/fast_commit.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02259
Уязвимость функции rapl_compute_time_window_core() в модуле drivers/powercap/intel_rapl_common.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02263
Уязвимость функции dbMount() в модуле fs/jfs/jfs_dmap.c файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02265
Уязвимость функции crypt_message() в модуле fs/cifs/smb2ops.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02270
Уязвимость функции destroy() в модуле drivers/md/dm-cache-target.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02277
Уязвимость функции ismt_access() модуля drivers/i2c/busses/i2c-ismt.c драйвера аппаратной шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2026-02280
Уязвимость функции jsm_probe_one() модуля drivers/tty/serial/jsm/jsm_driver.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02338
Уязвимость функции set_machine_constraints() в модуле drivers/regulator/core.c драйвера регуляторов напряжения и тока ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02339
Уязвимость функции sk_stream_wait_memory() в модуле net/core/stream.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02340
Уязвимость функции blk_mq_register_hctx() в модуле block/blk-mq-sysfs.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02341
Уязвимость функции add_all_parents() в модуле fs/btrfs/backref.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02343
Уязвимость функции rtas_os_term() в модуле arch/powerpc/kernel/rtas.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02357
Уязвимость функции ext4_clu_mapped() в модуле fs/ext4/extents.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02358
Уязвимость функции btrfs_drop_extents() в модуле fs/btrfs/file.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02367
Уязвимость функции nbd_start_device_ioctl() в модуле drivers/block/nbd.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02371
Уязвимость функции tsi148_dma_list_add() модуля drivers/staging/vme_user/vme_tsi148.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02372
Уязвимость функции msm_dsi_modeset_init() модуля drivers/gpu/drm/msm/dsi/dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02433
Уязвимость функции ge_b850v3_lvds_remove() модуля drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02434
Уязвимость функции hnae_ae_register() модуля drivers/net/ethernet/hisilicon/hns/hnae.c драйвера сетевых адаптеров Ethernet Hisilicon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02435
Уязвимость функции sfb_reset() модуля net/sched/sch_sfb.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02436
Уязвимость функции lpuart_dma_shutdown() модуля drivers/tty/serial/fsl_lpuart.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02437
Уязвимость функции nvme_trace_bio_complete() модуля [модуль] ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02439
Уязвимость функции setup_callback_client() модуля fs/nfsd/nfs4callback.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02440
Уязвимость функции udp_tunnel_sock_release() модуля net/ipv4/udp_tunnel_core.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02441
Уязвимость функции hci_conn_add_sysfs() модуля net/bluetooth/hci_sysfs.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02519
Уязвимость функции vub300_probe() модуля drivers/mmc/host/vub300.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02520
Уязвимость функции rtsx_pci_sdmmc_drv_probe() модуля drivers/mmc/host/rtsx_pci_sdmmc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02522
Уязвимость функции radeon_acpi_vfct_bios() модуля drivers/gpu/drm/radeon/radeon_bios.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02523
Уязвимость функции nlm_unlock_files() модуля fs/lockd/svcsubs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02525
Уязвимость функции get_dvsec_vendor0() модуля drivers/misc/ocxl/config.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02526
Уязвимость функции do_floppy_init() модуля drivers/block/floppy.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02630
Уязвимость функции ntfs_attr_find() в модуле fs/ntfs/attrib.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02631
Уязвимость функций p9_conn_cancel() и p9_read_work() в модуле net/9p/trans_fd.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02632
Уязвимость функции p9_fd_open() модуля net/9p/trans_fd.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02633
Уязвимость функции gfs2_check_sb() в модуле fs/gfs2/ops_fstype.c файловой системы GFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02634
Уязвимость функции snd_usbmidi_output_open() в модуле sound/usb/midi.c поддержки звуковых устройств USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02635
Уязвимость функции hugetlbfs_error_remove_page() в модуле fs/hugetlbfs/inode.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02636
Уязвимость функции btrfs_init_devices_late() в модуле fs/btrfs/volumes.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02637
Уязвимость функции add_widget_node() в модуле sound/hda/hdac_sysfs.c звуковой подсистнмы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02638
Уязвимость функции make_indexed_dir() в модуле fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02639
Уязвимость функции ext4_ext_migrate() в модуле fs/ext4/migrate.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03108
Уязвимость функции p9_conn_cancel() модуля net/9p/trans_fd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03266
Уязвимость функции brcmf_pcie_init_ringbuffers() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03269
Уязвимость функций list_version_get_needed() и __list_versions() модуля drivers/md/dm-ioctl.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03270
Уязвимость функции adv7511_remove() модуля drivers/gpu/drm/bridge/adv7511/adv7511_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03271
Уязвимость функции panfrost_ioctl_create_bo() модуля drivers/gpu/drm/panfrost/panfrost_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03279
Уязвимость функции do_get_hw_stats() модуля drivers/infiniband/hw/mlx5/counters.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03325
Уязвимость функций dlm_lowcomms_new_msg() и dlm_lowcomms_commit_msg() модуля fs/dlm/lowcomms.c поддержки распределенного менеджера блокировок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03584
Уязвимость функции cpufreq_policy_alloc() модуля drivers/cpufreq/cpufreq.c драйвера масштабирования частоты ЦП ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03639
Уязвимость функции ip_vs_app_net_cleanup() модуля net/netfilter/ipvs/ip_vs_app.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03682
Уязвимость функции free_policy_dbs_info() модуля drivers/cpufreq/cpufreq_governor.c драйвера поддержки масштабирования частоты ЦП ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03715
Уязвимость функций tcp_cdg_init() и tcp_cdg_release() модуля net/ipv4/tcp_cdg.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03718
Уязвимость функции __unregister_kprobe_top() модуля kernel/kprobes.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03719
Уязвимость функции tcm_loop_setup_hba_bus() модуля drivers/target/loopback/tcm_loop.c драйвера TCM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03721
Уязвимость функции zfcp_fsf_req_send() модуля drivers/s390/scsi/zfcp_fsf.c драйвера устройств SCSI на платформе S390 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03722
Уязвимость функции mp2629_read_raw() модуля drivers/iio/adc/mp2629_adc.c драйвера различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03723
Уязвимость функции ena_init() модуля drivers/net/ethernet/amazon/ena/ena_netdev.c драйвера сетевых адаптеров Ethernet Amazon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03724
Уязвимость функции kcm_splice_read() модуля net/kcm/kcmsock.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03725
Уязвимость функции mISDN_dsp_element_register() модуля drivers/isdn/mISDN/dsp_pipeline.c драйвера ISDN адаптеров ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03726
Уязвимость функции siox_device_add() модуля drivers/siox/siox-core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03727
Уязвимость функции setup_bootmem() модуля arch/riscv/mm/init.c подсистемы управления модулями платформы с архитектурой RISCV ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03728
Уязвимость модуля include/uapi/linux/capability.h ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03730
Уязвимость функции piix4_probe() модуля drivers/i2c/busses/i2c-piix4.c драйвера аппаратной шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03731
Уязвимость функций l2cap_rx_state_recv() и l2cap_rx() модуля net/bluetooth/l2cap_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03732
Уязвимость функций test_no_shared_qgroup() и test_multiple_refs() модуля fs/btrfs/tests/qgroup-tests.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03733
Уязвимость функций prelim_release() и find_parent_nodes() модуля fs/btrfs/backref.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03737
Уязвимость функций tcpci_register_port() и tcpci_unregister_port() модуля drivers/usb/typec/tcpm/tcpci.c драйвера диспетчера контроллеров портов USB TypeC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03767
Уязвимость функции cifs_create() модуля fs/cifs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-20
BDU:2026-03769
Уязвимость функции pnp_alloc_dev() модуля drivers/pnp/core.c ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, вызвать отказ в обслуживании
BDU:2026-03771
Уязвимость функции bridge_platform_create() модуля arch/mips/sgi-ip27/ip27-xtalk.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03772
Уязвимость функции pxa2xx_flash_probe() модуля drivers/mtd/maps/pxa2xx-flash.c драйвера доступа к устройствам памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03773
Уязвимость функции crb_acpi_add() модуля drivers/char/tpm/tpm_crb.c драйвера алфавитноцифровых устройств с TPM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03774
Уязвимость функции __cld_pipe_inprogress_downcall() модуля fs/nfsd/nfs4recover.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03777
Уязвимость функции p9_tag_alloc() модуля net/9p/client.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03778
Уязвимость функции fbcon_do_set_font() модуля drivers/video/fbdev/core/fbcon.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03812
Уязвимость функций rk3288_lvds_poweron() и px30_lvds_poweron() модуля drivers/gpu/drm/rockchip/rockchip_lvds.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03813
Уязвимость функции mpt3sas_transport_port_add() модуля drivers/scsi/mpt3sas/mpt3sas_transport.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03814
Уязвимость функции fake_init() модуля drivers/staging/vme_user/vme_fake.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03828
Уязвимость функции tipc_topsrv_kern_subscr() модуля net/tipc/topsrv.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03838
Уязвимость функции cifs_flock() модуля fs/cifs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03841
Уязвимость функции acpi_ut_copy_ipackage_to_ipackage() модуля drivers/acpi/acpica/utcopy.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03843
Уязвимость функции pl353_smc_probe() модуля drivers/memory/pl353-smc.c драйвера контроллера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03854
Уязвимость функции bitmap_ip_create() модуля net/netfilter/ipset/ip_set_bitmap_ip.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03909
Уязвимость функции ata_tport_add() модуля drivers/ata/libata-transport.c драйвера SATA/PATA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03917
Уязвимость функции register_synth_event() модуля kernel/trace/trace_events_synth.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03938
Уязвимость функции wwan_hwsim_dev_new() модуля drivers/net/wwan/wwan_hwsim.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03939
Уязвимость функции __unset_online() модуля drivers/s390/cio/css.c драйвера платформы S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03940
Уязвимость функции skb_append_pagefrags() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03944
Уязвимость функции cfctrl_linkup_request() модуля net/caif/cfctrl.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03962
Уязвимость функции smc_init() модуля net/smc/af_smc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03964
Уязвимость функции cifs_mount() модуля fs/cifs/connect.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03965
Уязвимость функций test_gen_synth_cmd() и test_empty_synth_event() модуля kernel/trace/synth_event_gen_test.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03966
Уязвимость функций qp_notify_peer_local() и qp_notify_peer() модуля drivers/misc/vmw_vmci/vmci_queue_pair.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03967
Уязвимость функции eprobe_trigger_func() модуля kernel/trace/trace_eprobe.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03969
Уязвимость функции amd_probe() модуля drivers/mmc/host/sdhci-pci-core.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03970
Уязвимость функций i8042_probe() и i8042_remove() модуля drivers/input/serio/i8042.c драйвера устройств ввода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03975
Уязвимость функции __mdiobus_register() модуля drivers/net/phy/mdio_bus.c драйвера сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03977
Уязвимость функции lapbeth_open() модуля drivers/net/wan/lapbether.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03980
Уязвимость функции nest_imc_event_init() модуля arch/powerpc/perf/imc-pmu.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03981
Уязвимость функции iio_sysfs_trigger_remove() модуля drivers/iio/trigger/iio-trig-sysfs.c драйвера различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03982
Уязвимость функции iforce_init_device() модуля drivers/input/joystick/iforce/iforce-main.c драйвера устройств ввода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04049
Уязвимость функции test_firmware_init() модуля lib/test_firmware.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04051
Уязвимость функции amdgpu_amdkfd_gpuvm_import_dmabuf() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04052
Уязвимость функции snd_ac97_dev_register() модуля sound/pci/ac97/ac97_codec.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04053
Уязвимость функции solo_sysfs_init() модуля drivers/media/pci/solo6x10/solo6x10-core.c драйвера мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04054
Уязвимость функции _samsung_clk_register_pll() модуля drivers/clk/samsung/clk-pll.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04055
Уязвимость функции i2sbus_add_dev() модуля sound/aoa/soundbus/i2sbus/core.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04058
Уязвимость функции ppr_notifier() модуля drivers/iommu/amd/iommu_v2.c драйвера IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04059
Уязвимость функции tegra210_clock_init() модуля drivers/clk/tegra/clk-tegra210.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04060
Уязвимость функции tegra20_clock_init() модуля drivers/clk/tegra/clk-tegra20.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04061
Уязвимость функции __open_metadata() модуля drivers/md/dm-thin-metadata.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04063
Уязвимость функции tcp_bpf_send_verdict() модуля net/ipv4/tcp_bpf.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04084
Уязвимость функции rpi_firmware_probe() модуля drivers/firmware/raspberrypi.c драйвера прошивок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04085
Уязвимость функции fsl_pamu_probe() модуля drivers/iommu/fsl_pamu.c драйвера IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04086
Уязвимость функции mipi_dsi_remove_device_fn() модуля drivers/gpu/drm/drm_mipi_dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04087
Уязвимость функции mpc52xx_lpbfifo_probe() модуля arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04088
Уязвимость функции ntfs_fill_super() модуля fs/ntfs3/super.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04089
Уязвимость функции hpre_probe() модуля drivers/crypto/hisilicon/hpre/hpre_main.c драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04092
Уязвимость функции intel_gvt_debugfs_add_vgpu() модуля drivers/gpu/drm/i915/gvt/debugfs.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04114
Уязвимость функции ext4_alloc_inode() модуля fs/ext4/super.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04409
Уязвимость функции smp_execute_task_sg() модуля drivers/scsi/libsas/sas_expander.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04437
Уязвимость функции sifive_gpio_probe() модуля drivers/gpio/gpio-sifive.c драйвера GPIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04513
Уязвимость функции gbaudio_dapm_free_controls() модуля drivers/staging/greybus/audio_helper.c драйвера устройств линейки Greybus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04555
Уязвимость функции ceph_update_snap_trace() модуля fs/ceph/snap.c поддержки распределенной файловой системы Ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04858
Уязвимость функции xhci_alloc_stream_info() модуля drivers/usb/host/xhci-mem.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04861
Уязвимость функций sti_dvo_connector_mode_valid() (drivers/gpu/drm/sti/sti_dvo.c), sti_hda_connector_mode_valid() (drivers/gpu/drm/sti/sti_hda.c) и sti_hdmi_connector_mode_valid() (drivers/gpu/drm/sti/sti_hdmi.c) драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04862
Уязвимость функции show_cpuinfo() модуля arch/um/kernel/um_arch.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04863
Уязвимость функции hugetlbfs_parse_param() модуля fs/hugetlbfs/inode.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04864
Уязвимость функции ext4_write_info() модуля fs/ext4/super.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04867
Уязвимость функции ext4_rename() модуля fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04868
Уязвимость функции buffer_prepare() модуля drivers/media/pci/cx88/cx88-video.c драйвера мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05626
Уязвимость функции ip6addrlbl_putmsg() в модуле net/ipv6/addrlabel.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-05733
Уязвимость функции usb_put_hcd() модуля drivers/usb/host/xhci-mtk.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05734
Уязвимость функции __dev_queue_xmit() модуля net/core/filter.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05735
Уязвимость функции alloc_huge_page() модуля mm/hugetlb.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05769
Уязвимость подсистемы switchdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05770
Уязвимость функции mhi_net_dellink() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05772
Уязвимость функции ata_tdev_add() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05773
Уязвимость функции ata_tport_add() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05774
Уязвимость функции drm_dev_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05775
Уязвимость функции pinctrl_dt_to_map() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05776
Уязвимость функции can_rx_register() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05777
Уязвимость функции napi_get_frags() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05778
Уязвимость функции cortex_a76_erratum_1463225_debug_handler() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05779
Уязвимость функций test_gen_kprobe/kretprobe_cmd() и test_gen_kprobe_cmd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05780
Уязвимость функций __ip_vs_cleanup_batch() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05783
Уязвимость функции xprt_switch sysfs() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05807
Уязвимость компонента macvlan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05808
Уязвимость функции kprobe_event_gen_test_exit() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05809
Уязвимость функции tracing_read_pipe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05810
Уязвимость функции ftrace_add_mod() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05812
Уязвимость функции ata_tlink_add() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05813
Уязвимость функции sctp_sched_fcfs_dequeue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05814
Уязвимость функции imx_uart_freeze() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05841
Уязвимость функции j1939_send_one() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05843
Уязвимость функции free_netdev() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05844
Уязвимость функции mousevsc_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05845
Уязвимость функции query_regdb_file() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05846
Уязвимость компонента ibmvnic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05847
Уязвимость функции mISDN_register_device() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05848
Уязвимость функции red_enqueue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05855
Уязвимость функции i2c_dw_xfer_msg() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05856
Уязвимость функции percpu_init_rwsem() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05857
Уязвимость функции ext4_fc_reserve_space() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05858
Уязвимость функции of_lpddr3_get_ddr_timings() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05859
Уязвимость функции ext4_unlink() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05860
Уязвимость функции des3_ede_encrypt() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05861
Уязвимость функции ioctl() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05862
Уязвимость функции getpeername() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05863
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05949
Уязвимость функции mhi_mbim_dellink() драйвера MHI ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05950
Уязвимость функции unix_gc() модуля fnet/unix/garbage.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05951
Уязвимость функций pci_init_afu() и cxl_pci_init_adapter() модуля drivers/misc/cxl/pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05952
Уязвимость функции of_get_ddr_timings() модуля drivers/memory/of_memory.c драйвера контроллера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05953
Уязвимость функций trace_string() и trace_event_raw_event_synth() модуля kernel/trace/trace_events_synth.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05954
Уязвимость функции sock_map_free() модуля net/core/sock_map.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05955
Уязвимость функции moxart_probe() модуля drivers/mmc/host/moxart-mmc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05956
Уязвимость функций vhost_vsock_alloc_pkt() (drivers/vhost/vsock.c) и virtio_transport_free_pkt() (net/vmw_vsock/virtio_transport_common.c) драйвера общей реализации IOTLB для vhost и vringh ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05968
Уязвимость функции sc7180_lpass_init() модуля sound/soc/qcom/lpass-sc7180.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05969
Уязвимость функции cxl_calc_capp_routing() модуля drivers/misc/cxl/pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05970
Уязвимость функции hswep_has_limit_sbox() модуля arch/x86/events/intel/uncore_snbep.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05971
Уязвимость функции arm_trbe_probe_cpuhp() модуля drivers/hwtracing/coresight/coresight-trbe.c драйвера трассировки HW ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05972
Уязвимость функции rtsx_usb_sdmmc_drv_probe() модуля drivers/mmc/host/rtsx_usb_sdmmc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05973
Уязвимость функции tifm_7xx1_switch_media() модуля drivers/misc/tifm_7xx1.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05974
Уязвимость функции wmt_mci_probe() модуля drivers/mmc/host/wmt-sdmmc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05975
Уязвимость функции __pskb_pull_tail() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05977
Уязвимость функции padata_do_parallel() модуля kernel/padata.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05978
Уязвимость функции hinic_init_cmdqs() модуля drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05979
Уязвимость функции mt8183_mt6358_ts3a227_max98357_dev_probe() модуля sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05980
Уязвимость функции integrity_init_keyring() модуля security/integrity/digsig.c подсистемы обеспечения безопасности ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05981
Уязвимость функции md_bitmap_resize() модуля drivers/md/md-bitmap.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05983
Уязвимость функции fcoe_init() модуля drivers/scsi/fcoe/fcoe.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05984
Уязвимость функции wpcm450_aic_of_init() модуля drivers/irqchip/irq-wpcm450-aic.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06027
Уязвимость функции md_end_flush() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06028
Уязвимость функции nfs_d_automount() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06050
Уязвимость функции sc_disable() ядра операционных систем Linux, позволяющая нарушителю вызвать сбой ядра
BDU:2026-06051
Уязвимость функции nf_flow_table_free() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06052
Уязвимость функции rcu_barrier() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06056
Уязвимость функции sk_stream_kill_queues() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06068
Уязвимость функции nfsd_init_dirlist_pages() в модуле fs/nfsd/nfsproc.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06069
Уязвимость функции qcom_cpufreq_probe() в модуле drivers/cpufreq/qcom-cpufreq-nvmem.c драйвера масштабирования частоты ЦП ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06070
Уязвимость функции iwl_mvm_tx_skb_sta() в модуле drivers/net/wireless/intel/iwlwifi/mvm/tx.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06072
Уязвимость функции az6027_i2c_xfer() в модуле drivers/media/usb/dvb-usb/az6027.c драйвера мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06073
Уязвимость функции power_supply_get_battery_info() в модуле drivers/power/supply/power_supply_core.c драйвера управления питанием ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06075
Уязвимость функции propagate_one() в модуле fs/pnode.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06076
Уязвимость функции cdev_device_add() в модуле fs/char_dev.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06078
Уязвимость функции send_eject_command() в модуле drivers/net/wireless/ath/ath9k/hif_usb.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06079
Уязвимость функции dump_zones() в модуле drivers/md/raid0.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06082
Уязвимость функции vub300_enable_sdio_irq() в модуле drivers/mmc/host/vub300.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06083
Уязвимость функции ext4_dio_write_iter() в модуле fs/ext4/file.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06084
Уязвимость функции hinic_dbg_get_func_table() в модуле drivers/net/ethernet/huawei/hinic/hinic_debugfs.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06085
Уязвимость функции mt8173_afe_pcm_dev_probe() в модуле sound/soc/mediatek/mt8173/mt8173-afe-pcm.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06089
Уязвимость функции cake_dequeue() в модуле net/sched/sch_cake.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06092
Уязвимость функции load_elf_binary() в модуле fs/binfmt_elf.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06093
Уязвимость функции cros_usbpd_notify_init() в модуле drivers/platform/chrome/cros_usbpd_notify.c поддержки платформы оборудования Chrome OS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-06
CVE-2022-3424
A use-after-free flaw was found in the Linux kernel’s SGI GRU driver in the way the first gru_file_unlocked_ioctl function is called by the user, where a fail pass occurs in the gru_check_chiplet_assignment function. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2132640
- https://github.com/torvalds/linux/commit/643a16a0eb1d6ac23744bb6e90a00fc21148a9dc
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20221019031445.901570-1-zyytlz.wz%40163.com/
- https://security.netapp.com/advisory/ntap-20230406-0005/
- https://www.spinics.net/lists/kernel/msg4518970.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2132640
- https://github.com/torvalds/linux/commit/643a16a0eb1d6ac23744bb6e90a00fc21148a9dc
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20221019031445.901570-1-zyytlz.wz%40163.com/
- https://security.netapp.com/advisory/ntap-20230406-0005/
- https://www.spinics.net/lists/kernel/msg4518970.html
Modified: 2024-11-21
CVE-2022-3545
A vulnerability has been found in Linux Kernel and classified as critical. Affected by this vulnerability is the function area_cache_get of the file drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211045 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=02e1a114fdb71e59ee6770294166c30d437bf86a
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20221223-0003/
- https://vuldb.com/?id.211045
- https://www.debian.org/security/2023/dsa-5324
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=02e1a114fdb71e59ee6770294166c30d437bf86a
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20221223-0003/
- https://vuldb.com/?id.211045
- https://www.debian.org/security/2023/dsa-5324
Modified: 2024-11-21
CVE-2022-3564
A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211087.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
Modified: 2024-11-21
CVE-2022-3565
A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function del_timer of the file drivers/isdn/mISDN/l1oip_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211088.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211088
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211088
Modified: 2024-11-21
CVE-2022-3623
A vulnerability was found in Linux Kernel. It has been declared as problematic. Affected by this vulnerability is the function follow_page_pte of the file mm/gup.c of the component BPF. The manipulation leads to race condition. The attack can be launched remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-211921 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://vuldb.com/?id.211921
- https://www.debian.org/security/2023/dsa-5324
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://vuldb.com/?id.211921
- https://www.debian.org/security/2023/dsa-5324
Modified: 2024-11-21
CVE-2022-3640
A vulnerability, which was classified as critical, was found in Linux Kernel. Affected is the function l2cap_conn_del of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211944.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
Modified: 2024-11-21
CVE-2022-3649
A vulnerability was found in Linux Kernel. It has been classified as problematic. Affected is the function nilfs_new_inode of the file fs/nilfs2/inode.c of the component BPF. The manipulation leads to use after free. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211992.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20230214-0009/
- https://vuldb.com/?id.211992
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20230214-0009/
- https://vuldb.com/?id.211992
Modified: 2025-03-28
CVE-2022-4139
An incorrect TLB flush issue was found in the Linux kernel’s GPU i915 kernel driver, potentially leading to random memory corruption or data leaks. This flaw could allow a local user to crash the system or escalate their privileges on the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2147572
- https://security.netapp.com/advisory/ntap-20230309-0004/
- https://www.openwall.com/lists/oss-security/2022/11/30/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2147572
- https://security.netapp.com/advisory/ntap-20230309-0004/
- https://www.openwall.com/lists/oss-security/2022/11/30/1
Modified: 2025-05-15
CVE-2022-41674
An issue was discovered in the Linux kernel before 5.19.16. Attackers able to inject WLAN frames could cause a buffer overflow in the ieee80211_bss_info_update function in net/mac80211/scan.c.
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- https://bugzilla.suse.com/show_bug.cgi?id=1203770
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://www.debian.org/security/2022/dsa-5257
- https://www.openwall.com/lists/oss-security/2022/10/13/5
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- https://bugzilla.suse.com/show_bug.cgi?id=1203770
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://www.debian.org/security/2022/dsa-5257
- https://www.openwall.com/lists/oss-security/2022/10/13/5
Modified: 2025-05-15
CVE-2022-42719
A use-after-free in the mac80211 stack when parsing a multi-BSSID element in the Linux kernel 5.2 through 5.19.x before 5.19.16 could be used by attackers (able to inject WLAN frames) to crash the kernel and potentially execute code.
- http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204051
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
- http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204051
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2025-05-15
CVE-2022-42720
Various refcounting bugs in the multi-BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.x before 5.19.16 could be used by local attackers (able to inject WLAN frames) to trigger use-after-free conditions to potentially execute code.
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204059
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204059
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2024-11-21
CVE-2022-42896
There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within proximity of the victim. We recommend upgrading past commit https://www.google.com/url https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url
Modified: 2025-04-10
CVE-2022-4378
A stack overflow flaw was found in the Linux kernel's SYSCTL subsystem in how a user changes certain kernel parameters and variables. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2152548
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-avoid-integer-type-confusion-in-get_proc_long.patch
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-proc_skip_spaces-shouldn-t-think-it-is-working-on-c-strings.patch
- https://seclists.org/oss-sec/2022/q4/178
- http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2152548
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-avoid-integer-type-confusion-in-get_proc_long.patch
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-proc_skip_spaces-shouldn-t-think-it-is-working-on-c-strings.patch
- https://seclists.org/oss-sec/2022/q4/178
Modified: 2025-04-29
CVE-2022-45934
An issue was discovered in the Linux kernel through 6.0.10. l2cap_config_req in net/bluetooth/l2cap_core.c has an integer wraparound via L2CAP_CONF_REQ packets.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=ae4569813a6e931258db627cdfe50dfb4f917d5d
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NDAKCGDW6CQ6G3RZWYZJO454R3L5CTQB/
- https://security.netapp.com/advisory/ntap-20230113-0008/
- https://www.debian.org/security/2023/dsa-5324
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=ae4569813a6e931258db627cdfe50dfb4f917d5d
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NDAKCGDW6CQ6G3RZWYZJO454R3L5CTQB/
- https://security.netapp.com/advisory/ntap-20230113-0008/
- https://www.debian.org/security/2023/dsa-5324
Modified: 2025-04-17
CVE-2022-47518
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of the number of channels in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when copying the list of operating channels from Wi-Fi management frames.
- https://github.com/torvalds/linux/commit/0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-5-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
- https://github.com/torvalds/linux/commit/0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-5-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
Modified: 2025-04-17
CVE-2022-47519
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_OPER_CHANNEL in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger an out-of-bounds write when parsing the channel list attribute from Wi-Fi management frames.
- https://github.com/torvalds/linux/commit/051ae669e4505abbe05165bebf6be7922de11f41
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-3-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
- https://github.com/torvalds/linux/commit/051ae669e4505abbe05165bebf6be7922de11f41
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-3-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
Modified: 2025-04-17
CVE-2022-47520
An issue was discovered in the Linux kernel before 6.0.11. Missing offset validation in drivers/net/wireless/microchip/wilc1000/hif.c in the WILC1000 wireless driver can trigger an out-of-bounds read when parsing a Robust Security Network (RSN) information element from a Netlink packet.
- https://github.com/torvalds/linux/commit/cd21d99e595ec1d8721e1058dcdd4f1f7de1d793
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-2-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
- https://github.com/torvalds/linux/commit/cd21d99e595ec1d8721e1058dcdd4f1f7de1d793
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-2-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
Modified: 2025-04-17
CVE-2022-47521
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_CHANNEL_LIST in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when parsing the operating channel attribute from Wi-Fi management frames.
- https://github.com/torvalds/linux/commit/f9b62f9843c7b0afdaecabbcebf1dbba18599408
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-4-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
- https://github.com/torvalds/linux/commit/f9b62f9843c7b0afdaecabbcebf1dbba18599408
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-4-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
Modified: 2025-02-27
CVE-2022-48424
In the Linux kernel before 6.1.3, fs/ntfs3/inode.c does not validate the attribute name offset. An unhandled page fault may occur.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f1dc7d9756e66f3f876839ea174df2e656b7f79
- https://security.netapp.com/advisory/ntap-20230505-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f1dc7d9756e66f3f876839ea174df2e656b7f79
- https://security.netapp.com/advisory/ntap-20230505-0002/
Modified: 2024-09-04
CVE-2022-48868
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Let probe fail when workqueue cannot be enabled The workqueue is enabled when the appropriate driver is loaded and disabled when the driver is removed. When the driver is removed it assumes that the workqueue was enabled successfully and proceeds to free allocations made during workqueue enabling. Failure during workqueue enabling does not prevent the driver from being loaded. This is because the error path within drv_enable_wq() returns success unless a second failure is encountered during the error path. By returning success it is possible to load the driver even if the workqueue cannot be enabled and allocations that do not exist are attempted to be freed during driver remove. Some examples of problematic flows: (a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq(). (b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010 Fix the drv_enable_wq() error path by returning the original error that indicates failure of workqueue enabling. This ensures that the probe fails when an error is encountered and the driver remove paths are only attempted when the workqueue was enabled successfully.
Modified: 2024-09-06
CVE-2022-48869
In the Linux kernel, the following vulnerability has been resolved:
USB: gadgetfs: Fix race between mounting and unmounting
The syzbot fuzzer and Gerald Lee have identified a use-after-free bug
in the gadgetfs driver, involving processes concurrently mounting and
unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super()
can race with gadgetfs_kill_sb(), causing the latter to deallocate
the_device while the former is using it. The output from KASAN says,
in part:
BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]
BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]
BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]
BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]
BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689
CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
- https://git.kernel.org/stable/c/616fd34d017000ecf9097368b13d8a266f4920b3
- https://git.kernel.org/stable/c/856e4b5e53f21edbd15d275dde62228dd94fb2b4
- https://git.kernel.org/stable/c/9a39f4626b361ee7aa10fd990401c37ec3b466ae
- https://git.kernel.org/stable/c/a2e075f40122d8daf587db126c562a67abd69cf9
- https://git.kernel.org/stable/c/d18dcfe9860e842f394e37ba01ca9440ab2178f4
Modified: 2024-09-06
CVE-2022-48870
In the Linux kernel, the following vulnerability has been resolved:
tty: fix possible null-ptr-defer in spk_ttyio_release
Run the following tests on the qemu platform:
syzkaller:~# modprobe speakup_audptr
input: Speakup as /devices/virtual/input/input4
initialized device: /dev/synth, node (MAJOR 10, MINOR 125)
speakup 3.1.6: initialized
synth name on entry is: (null)
synth probe
spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned
failed (errno -16), then remove the module, we will get a null-ptr-defer
problem, as follow:
syzkaller:~# modprobe -r speakup_audptr
releasing synth audptr
BUG: kernel NULL pointer dereference, address: 0000000000000080
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1
RIP: 0010:mutex_lock+0x14/0x30
Call Trace:
Modified: 2024-09-06
CVE-2022-48871
In the Linux kernel, the following vulnerability has been resolved: tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer.
Modified: 2024-09-06
CVE-2022-48872
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free race condition for maps It is possible that in between calling fastrpc_map_get() until map->fl->lock is taken in fastrpc_free_map(), another thread can call fastrpc_map_lookup() and get a reference to a map that is about to be deleted. Rewrite fastrpc_map_get() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted. Fixes this warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate ... Call trace: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_syscall
- https://git.kernel.org/stable/c/079c78c68714f7d8d58e66c477b0243b31806907
- https://git.kernel.org/stable/c/556dfdb226ce1e5231d8836159b23f8bb0395bf4
- https://git.kernel.org/stable/c/61a0890cb95afec5c8a2f4a879de2b6220984ef1
- https://git.kernel.org/stable/c/96b328d119eca7563c1edcc4e1039a62e6370ecb
- https://git.kernel.org/stable/c/b171d0d2cf1b8387c72c8d325c5d5746fa271e39
Modified: 2024-09-06
CVE-2022-48873
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Don't remove map on creater_process and device_release Do not remove the map from the list on error path in fastrpc_init_create_process, instead call fastrpc_map_put, to avoid use-after-free. Do not remove it on fastrpc_device_release either, call fastrpc_map_put instead. The fastrpc_free_map is the only proper place to remove the map. This is called only after the reference count is 0.
- https://git.kernel.org/stable/c/193cd853145b63e670bd73740250983af1475330
- https://git.kernel.org/stable/c/1b7b7bb400dd13dcb03fc6e591bb7ca4664bbec8
- https://git.kernel.org/stable/c/35ddd482345c43d9eec1f3406c0f20a95ed4054b
- https://git.kernel.org/stable/c/4b5c44e924a571d0ad07054de549624fbc04e4d7
- https://git.kernel.org/stable/c/5bb96c8f9268e2fdb0e5321cbc358ee5941efc15
Modified: 2024-09-04
CVE-2022-48875
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: sdata can be NULL during AMPDU start
ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a
deauthentication is ongoing.
Here a trace triggering the race with the hostapd test
multi_ap_fronthaul_on_ap:
(gdb) list *drv_ampdu_action+0x46
0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).
391 int ret = -EOPNOTSUPP;
392
393 might_sleep();
394
395 sdata = get_bss_sdata(sdata);
396 if (!check_sdata_in_driver(sdata))
397 return -EIO;
398
399 trace_drv_ampdu_action(local, sdata, params);
400
wlan0: moving STA 02:00:00:00:03:00 to state 3
wlan0: associated
wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)
wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0
wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)
wlan0: moving STA 02:00:00:00:03:00 to state 2
wlan0: moving STA 02:00:00:00:03:00 to state 1
wlan0: Removed STA 02:00:00:00:03:00
wlan0: Destroyed STA 02:00:00:00:03:00
BUG: unable to handle page fault for address: fffffffffffffb48
PGD 11814067 P4D 11814067 PUD 11816067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
Workqueue: phy3 ieee80211_ba_session_work [mac80211]
RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]
Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85
RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287
RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240
RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40
RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0
R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8
FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0
Call Trace:
Modified: 2024-09-05
CVE-2022-48877
In the Linux kernel, the following vulnerability has been resolved: f2fs: let's avoid panic if extent_tree is not created This patch avoids the below panic. pc : __lookup_extent_tree+0xd8/0x760 lr : f2fs_do_write_data_page+0x104/0x87c sp : ffffffc010cbb3c0 x29: ffffffc010cbb3e0 x28: 0000000000000000 x27: ffffff8803e7f020 x26: ffffff8803e7ed40 x25: ffffff8803e7f020 x24: ffffffc010cbb460 x23: ffffffc010cbb480 x22: 0000000000000000 x21: 0000000000000000 x20: ffffffff22e90900 x19: 0000000000000000 x18: ffffffc010c5d080 x17: 0000000000000000 x16: 0000000000000020 x15: ffffffdb1acdbb88 x14: ffffff888759e2b0 x13: 0000000000000000 x12: ffffff802da49000 x11: 000000000a001200 x10: ffffff8803e7ed40 x9 : ffffff8023195800 x8 : ffffff802da49078 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0000000000000006 x4 : ffffffc010cbba28 x3 : 0000000000000000 x2 : ffffffc010cbb480 x1 : 0000000000000000 x0 : ffffff8803e7ed40 Call trace: __lookup_extent_tree+0xd8/0x760 f2fs_do_write_data_page+0x104/0x87c f2fs_write_single_data_page+0x420/0xb60 f2fs_write_cache_pages+0x418/0xb1c __f2fs_write_data_pages+0x428/0x58c f2fs_write_data_pages+0x30/0x40 do_writepages+0x88/0x190 __writeback_single_inode+0x48/0x448 writeback_sb_inodes+0x468/0x9e8 __writeback_inodes_wb+0xb8/0x2a4 wb_writeback+0x33c/0x740 wb_do_writeback+0x2b4/0x400 wb_workfn+0xe4/0x34c process_one_work+0x24c/0x5bc worker_thread+0x3e8/0xa50 kthread+0x150/0x1b4
- https://git.kernel.org/stable/c/1c38cdc747f00daf7394535eae5afc4c503c59bb
- https://git.kernel.org/stable/c/2c129e868992621a739bdd57a5bffa3985ef1b91
- https://git.kernel.org/stable/c/557e85ff9afef6d45020b6f09357111d38033c31
- https://git.kernel.org/stable/c/72009139a661ade5cb1da4239734ed02fa1cfff0
- https://git.kernel.org/stable/c/dd83a9763e29ed7a21c8a43f7a62cd0a6bf74692
- https://git.kernel.org/stable/c/df9d44b645b83fffccfb4e28c1f93376585fdec8
- https://git.kernel.org/stable/c/ff85a1dbd90d29f73033177ff8d8de4a27d9721c
Modified: 2024-08-29
CVE-2022-48878
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Fix driver shutdown on closed serdev The driver shutdown callback (which sends EDL_SOC_RESET to the device over serdev) should not be invoked when HCI device is not open (e.g. if hci_dev_open_sync() failed), because the serdev and its TTY are not open either. Also skip this step if device is powered off (qca_power_shutdown()). The shutdown callback causes use-after-free during system reboot with Qualcomm Atheros Bluetooth: Unable to handle kernel paging request at virtual address 0072662f67726fd7 ... CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W 6.1.0-rt5-00325-g8a5f56bcfcca #8 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: tty_driver_flush_buffer+0x4/0x30 serdev_device_write_flush+0x24/0x34 qca_serdev_shutdown+0x80/0x130 [hci_uart] device_shutdown+0x15c/0x260 kernel_restart+0x48/0xac KASAN report: BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50 Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1 CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xdc/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x68/0x84 print_report+0x188/0x488 kasan_report+0xa4/0xf0 __asan_load8+0x80/0xac tty_driver_flush_buffer+0x1c/0x50 ttyport_write_flush+0x34/0x44 serdev_device_write_flush+0x48/0x60 qca_serdev_shutdown+0x124/0x274 device_shutdown+0x1e8/0x350 kernel_restart+0x48/0xb0 __do_sys_reboot+0x244/0x2d0 __arm64_sys_reboot+0x54/0x70 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x44/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xbc/0x140 el0t_64_sync+0x190/0x194
Modified: 2024-08-29
CVE-2022-48879
In the Linux kernel, the following vulnerability has been resolved: efi: fix NULL-deref in init error path In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated. Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer.
- https://git.kernel.org/stable/c/4ca71bc0e1995d15486cd7b60845602a28399cb5
- https://git.kernel.org/stable/c/585a0b2b3ae7903c6abee3087d09c69e955a7794
- https://git.kernel.org/stable/c/5fcf75a8a4c3e7ee9122d143684083c9faf20452
- https://git.kernel.org/stable/c/703c13fe3c9af557d312f5895ed6a5fda2711104
- https://git.kernel.org/stable/c/adc96d30f6503d30dc68670c013716f1d9fcc747
- https://git.kernel.org/stable/c/e2ea55564229e4bea1474af15b111b3a3043b76f
Modified: 2025-10-10
CVE-2022-48880
In the Linux kernel, the following vulnerability has been resolved: platform/surface: aggregator: Add missing call to ssam_request_sync_free() Although rare, ssam_request_sync_init() can fail. In that case, the request should be freed via ssam_request_sync_free(). Currently it is leaked instead. Fix this.
Modified: 2024-09-06
CVE-2022-48891
In the Linux kernel, the following vulnerability has been resolved: regulator: da9211: Use irq handler when ready If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us. If we enable the IRQ handler before its structures are ready, we crash. This patch fixes: [ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [ 1.316096] Call trace: [ 1.316101] blocking_notifier_call_chain+0x20/0xa8 [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [ 1.327823] regulator_notifier_call_chain+0x1c/0x2c [ 1.327825] da9211_irq_handler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154
- https://git.kernel.org/stable/c/02228f6aa6a64d588bc31e3267d05ff184d772eb
- https://git.kernel.org/stable/c/1c1afcb8839b91c09d211ea304faa269763b1f91
- https://git.kernel.org/stable/c/470f6a9175f13a53810734658c35cc5bba33be01
- https://git.kernel.org/stable/c/ad1336274f733a7cb1f87b5c5908165a2c14df53
- https://git.kernel.org/stable/c/d443308edbfb6e9e757b478af908515110d1efd5
- https://git.kernel.org/stable/c/d4aa749e046435f054e94ebf50cad143d6229fae
- https://git.kernel.org/stable/c/f75cde714e0a67f73ef169aa50d4ed77d04f7236
Modified: 2024-08-29
CVE-2022-48892
In the Linux kernel, the following vulnerability has been resolved: sched/core: Fix use-after-free bug in dup_user_cpus_ptr() Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel. Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). This time, it will affect all arches. Fix this bug by always clearing the user_cpus_ptr of the newly cloned/forked task before the copying process starts and check the user_cpus_ptr state of the source task under pi_lock. Note to stable, this patch won't be applicable to stable releases. Just copy the new dup_user_cpus_ptr() function over.
Modified: 2024-09-11
CVE-2022-48896
In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix pci device refcount leak As the comment of pci_get_domain_bus_and_slot() says, it returns a PCI device with refcount incremented, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(), pci_dev_put() is called to avoid leak.
- https://git.kernel.org/stable/c/112df4cd2b09acd64bcd18f5ef83ba5d07b34bf0
- https://git.kernel.org/stable/c/4c93422a54cd6a349988f42e1c6bf082cf4ea9d8
- https://git.kernel.org/stable/c/53cefa802f070d46c0c518f4865be2c749818a18
- https://git.kernel.org/stable/c/b93fb4405fcb5112c5739c5349afb52ec7f15c07
- https://git.kernel.org/stable/c/c49996c6aa03590e4ef5add8772cb6068d99fd59
Modified: 2024-09-11
CVE-2022-48898
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set. Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption. Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID Changes in v2: -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr() -- add more commit text Changes in v3: -- add Stephen suggested -- dp_aux_isr() return IRQ_XXX back to caller -- dp_ctrl_isr() return IRQ_XXX back to caller Changes in v4: -- split into two patches Changes in v5: -- delete empty line between tags Changes in v6: -- remove extra "that" and fixed line more than 75 char at commit text Patchwork: https://patchwork.freedesktop.org/patch/516121/
Modified: 2024-09-11
CVE-2022-48899
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix GEM handle creation UAF Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object.
- https://git.kernel.org/stable/c/011ecdbcd520c90c344b872ca6b4821f7783b2f8
- https://git.kernel.org/stable/c/19ec87d06acfab2313ee82b2a689bf0c154e57ea
- https://git.kernel.org/stable/c/52531258318ed59a2dc5a43df2eaf0eb1d65438e
- https://git.kernel.org/stable/c/68bcd063857075d2f9edfed6024387ac377923e2
- https://git.kernel.org/stable/c/adc48e5e408afbb01d261bd303fd9fbbbaa3e317
- https://git.kernel.org/stable/c/d01d6d2b06c0d8390adf8f3ba08aa60b5642ef73
Modified: 2025-10-08
CVE-2022-48945
In the Linux kernel, the following vulnerability has been resolved:
media: vivid: fix compose size exceed boundary
syzkaller found a bug:
BUG: unable to handle page fault for address: ffffc9000a3b1000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:memcpy_erms+0x6/0x10
[...]
Call Trace:
- https://git.kernel.org/stable/c/2f558c5208b0f70c8140e08ce09fcc84da48e789
- https://git.kernel.org/stable/c/54f259906039dbfe46c550011409fa16f72370f6
- https://git.kernel.org/stable/c/5edc3604151919da8da0fb092b71d7dce07d848a
- https://git.kernel.org/stable/c/8c0ee15d9a102c732d0745566d254040085d5663
- https://git.kernel.org/stable/c/94a7ad9283464b75b12516c5512541d467cefcf8
- https://git.kernel.org/stable/c/9c7fba9503b826f0c061d136f8f0c9f953ed18b9
- https://git.kernel.org/stable/c/ab54081a2843aefb837812fac5488cc8f1696142
- https://git.kernel.org/stable/c/ccb5392c4fea0e7d9f7ab35567e839d74cb3998b
- https://git.kernel.org/stable/c/f9d19f3a044ca651b0be52a4bf951ffe74259b9f
Modified: 2024-10-25
CVE-2022-48946
In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.
- https://git.kernel.org/stable/c/12a88f572d6d94b5c0b72e2d1782cc2e96ac06cf
- https://git.kernel.org/stable/c/1a075f4a549481ce6e8518d8379f193ccec6b746
- https://git.kernel.org/stable/c/4d835efd561dfb9bf5409f11f4ecd428d5d29226
- https://git.kernel.org/stable/c/63dbbd8f1499b0a161e701a04aa50148d60bd1f7
- https://git.kernel.org/stable/c/72f651c96c8aadf087fd782d551bf7db648a8c2e
- https://git.kernel.org/stable/c/7665857f88557c372da35534165721156756f77f
- https://git.kernel.org/stable/c/ae56d9a017724f130cf1a263dd82a78d2a6e3852
- https://git.kernel.org/stable/c/c8b6fa4511a7900db9fb0353b630d4d2ed1ba99c
- https://git.kernel.org/stable/c/cfe4c1b25dd6d2f056afc00b7c98bcb3dd0b1fc3
Modified: 2024-10-25
CVE-2022-48947
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@...
- https://git.kernel.org/stable/c/19a78143961a197de8502f4f29c453b913dc3c29
- https://git.kernel.org/stable/c/49d5867819ab7c744852b45509e8469839c07e0e
- https://git.kernel.org/stable/c/5550bbf709c323194881737fd290c4bada9e6ead
- https://git.kernel.org/stable/c/95f1847a361c7b4bf7d74c06ecb6968455082c1a
- https://git.kernel.org/stable/c/9fdc79b571434af7bc742da40a3405f038b637a7
- https://git.kernel.org/stable/c/ad528fde0702903208d0a79d88d5a42ae3fc235b
- https://git.kernel.org/stable/c/bcd70260ef56e0aee8a4fc6cd214a419900b0765
- https://git.kernel.org/stable/c/f3fe6817156a2ad4b06f01afab04638a34d7c9a6
Modified: 2024-10-29
CVE-2022-48948
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes.
- https://git.kernel.org/stable/c/06fd17ee92c8f1704c7e54ec0fd50ae0542a49a5
- https://git.kernel.org/stable/c/4972e3528b968665b596b5434764ff8fd9446d35
- https://git.kernel.org/stable/c/4c92670b16727365699fe4b19ed32013bab2c107
- https://git.kernel.org/stable/c/6b41a35b41f77821db24f2d8f66794b390a585c5
- https://git.kernel.org/stable/c/7b1f773277a72f9756d47a41b94e43506cce1954
- https://git.kernel.org/stable/c/b8fb1cba934ea122b50f13a4f9d6fc4fdc43d2be
- https://git.kernel.org/stable/c/bc8380fe5768c564f921f7b4eaba932e330b9e4b
- https://git.kernel.org/stable/c/c79538f32df12887f110dcd6b9c825b482905f24
- https://git.kernel.org/stable/c/d1a92bb8d697f170d93fe922da763d7d156b8841
Modified: 2024-10-29
CVE-2022-48949
In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.
- https://git.kernel.org/stable/c/367e1e3399dbc56fc669740c4ab60e35da632b0e
- https://git.kernel.org/stable/c/51fd5ede7ed42f272682a0c33d6f0767b3484a3d
- https://git.kernel.org/stable/c/a6629659af3f5c6a91e3914ea62554c975ab77f4
- https://git.kernel.org/stable/c/c383c7c35c7bc15e07a04eefa060a8a80cbeae29
- https://git.kernel.org/stable/c/c581439a977545d61849a72e8ed631cfc8a2a3c1
- https://git.kernel.org/stable/c/de5dc44370fbd6b46bd7f1a1e00369be54a041c8
- https://git.kernel.org/stable/c/ef1d739dd1f362aec081278ff92f943c31eb177a
- https://git.kernel.org/stable/c/f2479c3daaabccbac6c343a737615d0c595c6dc4
Modified: 2024-10-25
CVE-2022-48950
In the Linux kernel, the following vulnerability has been resolved: perf: Fix perf_pending_task() UaF Per syzbot it is possible for perf_pending_task() to run after the event is free()'d. There are two related but distinct cases: - the task_work was already queued before destroying the event; - destroying the event itself queues the task_work. The first cannot be solved using task_work_cancel() since perf_release() itself might be called from a task_work (____fput), which means the current->task_works list is already empty and task_work_cancel() won't be able to find the perf_pending_task() entry. The simplest alternative is extending the perf_event lifetime to cover the task_work. The second is just silly, queueing a task_work while you know the event is going away makes no sense and is easily avoided by re-arranging how the event is marked STATE_DEAD and ensuring it goes through STATE_OFF on the way down.
Modified: 2024-10-25
CVE-2022-48951
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() The bounds checks in snd_soc_put_volsw_sx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks.
- https://git.kernel.org/stable/c/1798b62d642e7b3d4ea3403914c3caf4e438465d
- https://git.kernel.org/stable/c/18a168d85eadcfd45f015b5ecd2a97801b959e43
- https://git.kernel.org/stable/c/50b5f6d4d9d2d69a7498c44fd8b26e13d73d3d98
- https://git.kernel.org/stable/c/56288987843c3cb343e81e5fa51549cbaf541bd0
- https://git.kernel.org/stable/c/9796d07c753164b7e6b0d7ef23fb4482840a9ef8
- https://git.kernel.org/stable/c/97eea946b93961fffd29448dcda7398d0d51c4b2
- https://git.kernel.org/stable/c/cf1c225f1927891ae388562b78ced7840c3723b9
- https://git.kernel.org/stable/c/cf611d786796ec33da09d8c83d7d7f4e557b27de
Modified: 2024-10-25
CVE-2022-48952
In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel.
Modified: 2024-10-25
CVE-2022-48953
In the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit.
Modified: 2024-10-24
CVE-2022-48954
In the Linux kernel, the following vulnerability has been resolved: s390/qeth: fix use-after-free in hsci KASAN found that addr was dereferenced after br2dev_event_work was freed. ================================================================== BUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0 Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Hardware name: IBM 8561 T01 703 (LPAR) Workqueue: 0.0.8000_event qeth_l2_br2dev_worker Call Trace: [<000000016944d4ce>] dump_stack_lvl+0xc6/0xf8 [<000000016942cd9c>] print_address_description.constprop.0+0x34/0x2a0 [<000000016942d118>] print_report+0x110/0x1f8 [<0000000167a7bd04>] kasan_report+0xfc/0x128 [<000000016938d79a>] qeth_l2_br2dev_worker+0x5ba/0x6b0 [<00000001673edd1e>] process_one_work+0x76e/0x1128 [<00000001673ee85c>] worker_thread+0x184/0x1098 [<000000016740718a>] kthread+0x26a/0x310 [<00000001672c606a>] __ret_from_fork+0x8a/0xe8 [<00000001694711da>] ret_from_fork+0xa/0x40 Allocated by task 108338: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 __kasan_kmalloc+0xa0/0xc0 qeth_l2_switchdev_event+0x25a/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Freed by task 540: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 kasan_save_free_info+0x4c/0x68 ____kasan_slab_free+0x14e/0x1a8 __kasan_slab_free+0x24/0x30 __kmem_cache_free+0x168/0x338 qeth_l2_br2dev_worker+0x154/0x6b0 process_one_work+0x76e/0x1128 worker_thread+0x184/0x1098 kthread+0x26a/0x310 __ret_from_fork+0x8a/0xe8 ret_from_fork+0xa/0x40 Last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 insert_work+0x56/0x2e8 __queue_work+0x4ce/0xd10 queue_work_on+0xf4/0x100 qeth_l2_switchdev_event+0x520/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Second to last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 kvfree_call_rcu+0xb2/0x760 kernfs_unlink_open_file+0x348/0x430 kernfs_fop_release+0xc2/0x320 __fput+0x1ae/0x768 task_work_run+0x1bc/0x298 exit_to_user_mode_prepare+0x1a0/0x1a8 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 The buggy address belongs to the object at 00000000fdcea400 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 64 bytes inside of 96-byte region [00000000fdcea400, 00000000fdcea460) The buggy address belongs to the physical page: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 00000000fdcea380: fb fb fb fb fb fb f ---truncated---
Modified: 2024-10-24
CVE-2022-48955
In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: fix memory leak in tbnet_open() When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in tb_xdomain_alloc_out_hopid() is not released. Add tb_xdomain_release_out_hopid() to the error path to release ida.
Modified: 2024-10-24
CVE-2022-48956
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid use-after-free in ip6_fragment()
Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.
It seems to not be always true, at least for UDP stack.
syzbot reported:
BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]
BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618
CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
- https://git.kernel.org/stable/c/6b6d3be3661bff2746cab26147bd629aa034e094
- https://git.kernel.org/stable/c/7390c70bd431cbfa6951477e2c80a301643e284b
- https://git.kernel.org/stable/c/7e0dcd5f3ade221a6126278aca60c8ab4cc3bce9
- https://git.kernel.org/stable/c/803e84867de59a1e5d126666d25eb4860cfd2ebe
- https://git.kernel.org/stable/c/8208d7e56b1e579320b9ff3712739ad2e63e1f86
- https://git.kernel.org/stable/c/9b1a468a455d8319041528778d0e684a4c062792
- https://git.kernel.org/stable/c/b3d7ff8c04a83279fb7641fc4d5aa82a602df7c0
Modified: 2024-10-24
CVE-2022-48957
In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove() The cmd_buff needs to be freed when error happened in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove().
Modified: 2024-10-24
CVE-2022-48958
In the Linux kernel, the following vulnerability has been resolved: ethernet: aeroflex: fix potential skb leak in greth_init_rings() The greth_init_rings() function won't free the newly allocated skb when dma_mapping_error() returns error, so add dev_kfree_skb() to fix it. Compile tested only.
- https://git.kernel.org/stable/c/063a932b64db3317ec020c94466fe52923a15f60
- https://git.kernel.org/stable/c/223654e2e2c8d05347cd8e300f8d1ec6023103dd
- https://git.kernel.org/stable/c/87277bdf2c370ab2d07cfe77dfa9b37f82bbe1e5
- https://git.kernel.org/stable/c/99669d94ce145389f1d6f197e6e18ed50d43fb76
- https://git.kernel.org/stable/c/bfaa8f6c5b84b295dd73b0138b57c5555ca12b1c
- https://git.kernel.org/stable/c/c7adcbd0fd3fde1b19150c3e955fb4a30c5bd9b7
- https://git.kernel.org/stable/c/cb1e293f858e5e1152b8791047ed4bdaaf392189
- https://git.kernel.org/stable/c/dd62867a6383f78f75f07039394aac25924a3307
Modified: 2024-10-24
CVE-2022-48959
In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions() When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(), priv->regions is not released.
Modified: 2024-10-24
CVE-2022-48960
In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hix5hd2_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.
- https://git.kernel.org/stable/c/179499e7a240b2ef590f05eb379c810c26bbc8a4
- https://git.kernel.org/stable/c/1b6360a093ab8969c91a30bb58b753282e2ced4c
- https://git.kernel.org/stable/c/3a4eddd1cb023a71df4152fcc76092953e6fe95a
- https://git.kernel.org/stable/c/433c07a13f59856e4585e89e86b7d4cc59348fab
- https://git.kernel.org/stable/c/8067cd244cea2c332f8326842fd10158fa2cb64f
- https://git.kernel.org/stable/c/93aaa4bb72e388f6a4887541fd3d18b84f1b5ddc
- https://git.kernel.org/stable/c/b6307f7a2fc1c5407b6176f2af34a95214a8c262
- https://git.kernel.org/stable/c/b8ce0e6f9f88a6bb49d291498377e61ea27a5387
Modified: 2024-10-24
CVE-2022-48961
In the Linux kernel, the following vulnerability has been resolved: net: mdio: fix unbalanced fwnode reference count in mdio_device_release() There is warning report about of_node refcount leak while probing mdio device: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4 In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly. After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.
Modified: 2024-10-24
CVE-2022-48962
In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hisi_femac_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.
- https://git.kernel.org/stable/c/196e12671cb629d9f3b77b4d8bec854fc445533a
- https://git.kernel.org/stable/c/296a50aa8b2982117520713edc1375777a9f8506
- https://git.kernel.org/stable/c/3501da8eb6d0f5f114a09ec953c54423f6f35885
- https://git.kernel.org/stable/c/4640177049549de1a43e9bc49265f0cdfce08cfd
- https://git.kernel.org/stable/c/6f4798ac9c9e98f41553c4f5e6c832c8860a6942
- https://git.kernel.org/stable/c/8595a2db8eb0ffcbb466eb9f4a7507a5ba06ebb9
- https://git.kernel.org/stable/c/aceec8ab752428d8e151321479e82cc1a40fee2e
- https://git.kernel.org/stable/c/e71a46cc8c9ad75f3bb0e4b361e81f79c0214cca
Modified: 2024-10-25
CVE-2022-48965
In the Linux kernel, the following vulnerability has been resolved: gpio/rockchip: fix refcount leak in rockchip_gpiolib_register() The node returned by of_get_parent() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the end of of_pinctrl_get().
Modified: 2024-10-25
CVE-2022-48966
In the Linux kernel, the following vulnerability has been resolved: net: mvneta: Prevent out of bounds read in mvneta_config_rss() The pp->indir[0] value comes from the user. It is passed to: if (cpu_online(pp->rxq_def)) inside the mvneta_percpu_elect() function. It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap.
- https://git.kernel.org/stable/c/146ebee8fcdb349d7ec0e49915e6cdafb92544ae
- https://git.kernel.org/stable/c/3ceffb8f410b93553fb16fe7e84aa0d35b3ba79b
- https://git.kernel.org/stable/c/47a1a2f6cd5ec3a4f8a2d9bfa1e0605347cdb92c
- https://git.kernel.org/stable/c/5a142486a0db6b0b85031f22d69acd0cdcf8f72b
- https://git.kernel.org/stable/c/6ca0a506dddc3e1d636935eef339576b263bf3d8
- https://git.kernel.org/stable/c/a6b30598fec84f8809f5417cde73071ca43e8471
- https://git.kernel.org/stable/c/e8b4fc13900b8e8be48debffd0dfd391772501f7
- https://git.kernel.org/stable/c/eec1fc21edc2bb99c9e66cf66f0b5d4d643fbb50
Modified: 2024-10-25
CVE-2022-48967
In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.
- https://git.kernel.org/stable/c/27eb2d7a1b9987b6d0429b7716b1ff3b82c4ffc9
- https://git.kernel.org/stable/c/6778434706940b8fad7ef35f410d2b9929f256d2
- https://git.kernel.org/stable/c/6b37f0dc0638d13a006f2f24d2f6ca61e83bc714
- https://git.kernel.org/stable/c/908b2da426fe9c3ce74cf541ba40e7a4251db191
- https://git.kernel.org/stable/c/cff35329070b96b4484d23f9f48a5ca2c947e750
- https://git.kernel.org/stable/c/dbdcfb9f6748218a149f62468d6297ce3f014e9c
- https://git.kernel.org/stable/c/e329e71013c9b5a4535b099208493c7826ee4a64
- https://git.kernel.org/stable/c/f41547546db9af99da2c34e3368664d7a79cefae
Modified: 2024-10-25
CVE-2022-48968
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential memory leak in otx2_init_tc() In otx2_init_tc(), if rhashtable_init() failed, it does not free tc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap().
Modified: 2024-10-25
CVE-2022-48969
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time
- https://git.kernel.org/stable/c/99859947517e446058ad7243ee81d2f9801fa3dd
- https://git.kernel.org/stable/c/d50b7914fae04d840ce36491d22133070b18cca9
- https://git.kernel.org/stable/c/e6860c889f4ad50b6ab696f5ea154295d72cf27a
- https://git.kernel.org/stable/c/e6e897d4fe2f89c0bd94600a40bedf5e6e75e050
- https://git.kernel.org/stable/c/ed773dd798bf720756d20021b8d8a4a3d7184bda
- https://git.kernel.org/stable/c/f2dd60fd3fe98bd36a91b0c6e10bfe9d66258f84
Modified: 2024-10-25
CVE-2022-48970
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Get user_ns from in_skb in unix_diag_get_exact().
Wei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosed
the root cause: in unix_diag_get_exact(), the newly allocated skb does not
have sk. [2]
We must get the user_ns from the NETLINK_CB(in_skb).sk and pass it to
sk_diag_fill().
[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000270
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:sk_user_ns include/net/sock.h:920 [inline]
RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline]
RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170
Code: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8
54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b
9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d
RSP: 0018:ffffc90000d67968 EFLAGS: 00010246
RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d
RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270
RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000
R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800
R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940
FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/575a6266f63dbb3b8eb1da03671451f0d81b8034
- https://git.kernel.org/stable/c/5c014eb0ed6c8c57f483e94cc6e90f34ce426d91
- https://git.kernel.org/stable/c/9c1d6f79a2c7b8221dcec27defc6dc461052ead4
- https://git.kernel.org/stable/c/b3abe42e94900bdd045c472f9c9be620ba5ce553
- https://git.kernel.org/stable/c/c66d78aee55dab72c92020ebfbebc464d4f5dd2a
Modified: 2024-10-25
CVE-2022-48971
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix not cleanup led when bt_init fails
bt_init() calls bt_leds_init() to register led, but if it fails later,
bt_leds_cleanup() is not called to unregister it.
This can cause panic if the argument "bluetooth-power" in text is freed
and then another led_trigger_register() tries to access it:
BUG: unable to handle page fault for address: ffffffffc06d3bc0
RIP: 0010:strcmp+0xc/0x30
Call Trace:
- https://git.kernel.org/stable/c/2c6cf0afc3856359e620e96edd952457d258e16c
- https://git.kernel.org/stable/c/2f3957c7eb4e07df944169a3e50a4d6790e1c744
- https://git.kernel.org/stable/c/5ecf7cd6fde5e72c87122084cf00d63e35d8dd9f
- https://git.kernel.org/stable/c/8a66c3a94285552f6a8e45d73b34ebbad11d388b
- https://git.kernel.org/stable/c/e7b950458156d410509a08c41930b75e72985938
- https://git.kernel.org/stable/c/edf7284a98296369dd0891a0457eec37df244873
Modified: 2024-10-25
CVE-2022-48972
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()
Kernel fault injection test reports null-ptr-deref as follows:
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114
Call Trace:
- https://git.kernel.org/stable/c/1831d4540406708e48239cf38fd9c3b7ea98e08f
- https://git.kernel.org/stable/c/42c319635c0cf7eb36eccac6cda76532f47b61a3
- https://git.kernel.org/stable/c/623918f40fa68e3bb21312a3fafb90f491bf5358
- https://git.kernel.org/stable/c/7410f4d1221bb182510b7778ab6eefa8b9b7102d
- https://git.kernel.org/stable/c/9980a3ea20de40c83817877106c909cb032692d2
- https://git.kernel.org/stable/c/a110287ef4a423980309490df632e1c1e73b3dc9
- https://git.kernel.org/stable/c/b3d72d3135d2ef68296c1ee174436efd65386f04
- https://git.kernel.org/stable/c/f00c84fb1635c27ba24ec5df65d5bd7d7dc00008
Modified: 2024-10-25
CVE-2022-48973
In the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pci_dev_put() in amd_gpio_exit().
- https://git.kernel.org/stable/c/4271515f189bd5fe2ec86b4089dab7cb804625d2
- https://git.kernel.org/stable/c/45fecdb9f658d9c82960c98240bc0770ade19aca
- https://git.kernel.org/stable/c/4749c5cc147c9860b96db1e71cc36d1de1bd3f59
- https://git.kernel.org/stable/c/48bd5d3801f6b67cc144449d434abbd5043a6d37
- https://git.kernel.org/stable/c/5ee6413d3dd972930af787b2c0c7aaeb379fa521
- https://git.kernel.org/stable/c/71d591ef873f9ebb86cd8d053b3caee785b2de6a
- https://git.kernel.org/stable/c/b2bc053ebbba57a06fa655db5ea796de2edce445
- https://git.kernel.org/stable/c/e364ce04d8f840478b09eee57b614de7cf1e743e
Modified: 2024-10-25
CVE-2022-48975
In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device. However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del(). Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable.
Modified: 2024-10-25
CVE-2022-48977
In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rcv_filter Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer dereference in can_rx_register()") we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device") the check for dev->type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly.
- https://git.kernel.org/stable/c/0acc442309a0a1b01bcdaa135e56e6398a49439c
- https://git.kernel.org/stable/c/3982652957e8d79ac32efcb725450580650a8644
- https://git.kernel.org/stable/c/c142cba37de29f740a3852f01f59876af8ae462a
- https://git.kernel.org/stable/c/c42221efb1159d6a3c89e96685ee38acdce86b6f
- https://git.kernel.org/stable/c/fcc63f2f7ee3038d53216edd0d8291e57c752557
Modified: 2024-10-25
CVE-2022-48978
In the Linux kernel, the following vulnerability has been resolved:
HID: core: fix shift-out-of-bounds in hid_report_raw_event
Syzbot reported shift-out-of-bounds in hid_report_raw_event.
microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >
32! (swapper/0)
======================================================================
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/26/2022
Call Trace:
- https://git.kernel.org/stable/c/151493fe5a6ed1a88decc929a7368a3f2a246914
- https://git.kernel.org/stable/c/2b3b4d7aadaa1b6b58d0f34823bf86cfe8a31b4d
- https://git.kernel.org/stable/c/809783f8b4b600c7fb3bccb10fefef822601ea3b
- https://git.kernel.org/stable/c/8e14f20e12224ee2429f75a5c9418a700e26a8d3
- https://git.kernel.org/stable/c/bc03f809da78fc79e4aee132d4e5c6a2b3aeec73
- https://git.kernel.org/stable/c/db1ed1b3fb4ec0d19080a102956255769bc45c79
- https://git.kernel.org/stable/c/ec61b41918587be530398b0d1c9a0d16619397e5
- https://git.kernel.org/stable/c/f755d11c55b29049b77da5cd9ab2faae96eb33c3
Modified: 2024-10-25
CVE-2022-48980
In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing() The SJA1105 family has 45 L2 policing table entries (SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110 (SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but accounting for the difference in port count (5 in SJA1105 vs 10 in SJA1110) does not fully explain the difference. Rather, the SJA1110 also has L2 ingress policers for multicast traffic. If a packet is classified as multicast, it will be processed by the policer index 99 + SRCPORT. The sja1105_init_l2_policing() function initializes all L2 policers such that they don't interfere with normal packet reception by default. To have a common code between SJA1105 and SJA1110, the index of the multicast policer for the port is calculated because it's an index that is out of bounds for SJA1105 but in bounds for SJA1110, and a bounds check is performed. The code fails to do the proper thing when determining what to do with the multicast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast" index will be equal to 45, which is also equal to table->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes through the check. But at the same time, SJA1105 doesn't have multicast policers. So the code programs the SHARINDX field of an out-of-bounds element in the L2 Policing table of the static config. The comparison between index 45 and 45 entries should have determined the code to not access this policer index on SJA1105, since its memory wasn't even allocated. With enough bad luck, the out-of-bounds write could even overwrite other valid kernel data, but in this case, the issue was detected using KASAN. Kernel log: sja1105 spi5.0: Probed switch chip: SJA1105Q ================================================================== BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340 Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8 ... Workqueue: events_unbound deferred_probe_work_func Call trace: ... sja1105_setup+0x1cbc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ... Allocated by task 8: ... sja1105_setup+0x1bcc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ...
Modified: 2024-10-25
CVE-2022-48981
In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove errant put in error path drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free.
- https://git.kernel.org/stable/c/24013314be6ee4ee456114a671e9fa3461323de8
- https://git.kernel.org/stable/c/585a07b820059462e0c93b76c7de2cd946b26b40
- https://git.kernel.org/stable/c/586847b98e20ab02212ca5c1fc46680384e68a28
- https://git.kernel.org/stable/c/6a4da05acd062ae7774b6b19cef2b7d922902d36
- https://git.kernel.org/stable/c/83e3da8bb92fcfa7a1d232cf55f9e6c49bb84942
Modified: 2025-09-08
CVE-2022-48982
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix crash when replugging CSR fake controllers
It seems fake CSR 5.0 clones can cause the suspend notifier to be
registered twice causing the following kernel panic:
[ 71.986122] Call Trace:
[ 71.986124]
Modified: 2024-10-25
CVE-2022-48983
In the Linux kernel, the following vulnerability has been resolved:
io_uring: Fix a null-ptr-deref in io_tctx_exit_cb()
Syzkaller reports a NULL deref bug as follows:
BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3
Read of size 4 at addr 0000000000000138 by task file1/1955
CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
Modified: 2024-11-07
CVE-2022-48985
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix race on per-CQ variable napi work_done After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->work_done. If the other thread (for example, from busy_poll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic. To fix this issue, save the per-CQ work_done variable in a local variable before napi_complete_done(), so it won't be corrupted by a possible concurrent thread after napi_complete_done(). Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done variable race is fixed, so the driver is able to reliably support features like busy_poll.
Modified: 2024-11-01
CVE-2022-48986
In the Linux kernel, the following vulnerability has been resolved:
mm/gup: fix gup_pud_range() for dax
For dax pud, pud_huge() returns true on x86. So the function works as long
as hugetlb is configured. However, dax doesn't depend on hugetlb.
Commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") fixed
devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as
well.
This fixes the below kernel panic:
general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP
< snip >
Call Trace:
- https://git.kernel.org/stable/c/04edfa3dc06ecfc6133a33bc7271298782dee875
- https://git.kernel.org/stable/c/3ac29732a2ffa64c7de13a072b0f2848b9c11037
- https://git.kernel.org/stable/c/e06d13c36ded750c72521b600293befebb4e56c5
- https://git.kernel.org/stable/c/f1cf856123ceb766c49967ec79b841030fa1741f
- https://git.kernel.org/stable/c/fcd0ccd836ffad73d98a66f6fea7b16f735ea920
Modified: 2024-11-01
CVE-2022-48988
In the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type.
- https://git.kernel.org/stable/c/0ed074317b835caa6c03bcfa8f133365324673dc
- https://git.kernel.org/stable/c/35963b31821920908e397146502066f6b032c917
- https://git.kernel.org/stable/c/4a7ba45b1a435e7097ca0f79a847d0949d0eb088
- https://git.kernel.org/stable/c/aad8bbd17a1d586005feb9226c2e9cfce1432e13
- https://git.kernel.org/stable/c/b77600e26fd48727a95ffd50ba1e937efb548125
- https://git.kernel.org/stable/c/e1ae97624ecf400ea56c238bff23e5cd139df0b8
- https://git.kernel.org/stable/c/f1f7f36cf682fa59db15e2089039a2eeb58ff2ad
Modified: 2024-11-07
CVE-2022-48991
In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of the security impact of this only came in commit 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP"), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.
- https://git.kernel.org/stable/c/1a3f8c6cd29d9078cc81b29d39d0e9ae1d6a03c3
- https://git.kernel.org/stable/c/275c626c131cfe141beeb6c575e31fa53d32da19
- https://git.kernel.org/stable/c/5450535901d89a5dcca5fbbc59a24fe89caeb465
- https://git.kernel.org/stable/c/5ffc2a75534d9d74d49760f983f8eb675fa63d69
- https://git.kernel.org/stable/c/7f445ca2e0e59c7971d0b7b853465e50844ab596
- https://git.kernel.org/stable/c/c23105673228c349739e958fa33955ed8faddcaf
- https://git.kernel.org/stable/c/f268f6cf875f3220afc77bdd0bf1bb136eb54db9
- https://git.kernel.org/stable/c/ff2a1a6f869650aec99e9d070b5ab625bfbc5bc3
Modified: 2024-10-25
CVE-2022-48992
In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-pcm: Add NULL check in BE reparenting Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test.
- https://git.kernel.org/stable/c/0760acc2e6598ad4f7bd3662db2d907ef0838139
- https://git.kernel.org/stable/c/34a9796bf0684bfd54e96a142560d560c21c983b
- https://git.kernel.org/stable/c/9f74b9aa8d58c18927bb9b65dd5ba70a5fd61615
- https://git.kernel.org/stable/c/d4dd21a79dbb862d2ebcf9ed90e646416009ff0d
- https://git.kernel.org/stable/c/db8f91d424fe0ea6db337aca8bc05908bbce1498
- https://git.kernel.org/stable/c/e7166d6821c15f3516bcac8ae3f155924da1908c
- https://git.kernel.org/stable/c/f2ba66d8738584d124aff4e760ed1337f5f6dfb6
- https://git.kernel.org/stable/c/f6f45e538328df9ce66aa61bafee1a5717c4b700
Modified: 2024-11-07
CVE-2022-48994
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.
- https://git.kernel.org/stable/c/05530ef7cf7c7d700f6753f058999b1b5099a026
- https://git.kernel.org/stable/c/13ee8fb5410b740c8dd2867d3557c7662f7dda2d
- https://git.kernel.org/stable/c/15c42ab8d43acb73e2eba361ad05822c0af0ecfa
- https://git.kernel.org/stable/c/2f46e95bf344abc4e74f8158901d32a869e0adb6
- https://git.kernel.org/stable/c/63badfed200219ca656968725f1a43df293ac936
- https://git.kernel.org/stable/c/b38486e82ecb9f3046e0184205f6b61408fc40c9
- https://git.kernel.org/stable/c/e385360705a0b346bdb57ce938249175d0613b8a
- https://git.kernel.org/stable/c/fccd454129f6a0739651f7f58307cdb631fd6e89
Modified: 2024-10-25
CVE-2022-48995
In the Linux kernel, the following vulnerability has been resolved: Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send() There is a kmemleak when test the raydium_i2c_ts with bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff88812d3675c8 (size 8): comm "python3", pid 349, jiffies 4294741070 (age 95.692s) hex dump (first 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 After BANK_SWITCH command from i2c BUS, no matter success or error happened, the tx_buf should be freed.
Modified: 2024-11-07
CVE-2022-48997
In the Linux kernel, the following vulnerability has been resolved: char: tpm: Protect tpm_pm_suspend with locks Currently tpm transactions are executed unconditionally in tpm_pm_suspend() function, which may lead to races with other tpm accessors in the system. Specifically, the hw_random tpm driver makes use of tpm_get_random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Call Trace: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350 Fix this by calling tpm_try_get_ops(), which itself is a wrapper around tpm_chip_start(), but takes the appropriate mutex. [Jason: reworked commit message, added metadata]
- https://git.kernel.org/stable/c/23393c6461422df5bf8084a086ada9a7e17dc2ba
- https://git.kernel.org/stable/c/25b78bf98b07ff5aceb9b1e24f72ec0236c5c053
- https://git.kernel.org/stable/c/4e0d6c687c925e27fd4bc78a2721d10acf5614d6
- https://git.kernel.org/stable/c/571b6bbbf54d835ea6120f65575cb55cd767e603
- https://git.kernel.org/stable/c/d699373ac5f3545243d3c73a1ccab77fdef8cec6
Modified: 2024-10-31
CVE-2022-48999
In the Linux kernel, the following vulnerability has been resolved: ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference Gwangun Jung reported a slab-out-of-bounds access in fib_nh_match: fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961 fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753 inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874 Separate nexthop objects are mutually exclusive with the legacy multipath spec. Fix fib_nh_match to return if the config for the to be deleted route contains a multipath spec while the fib_info is using a nexthop object.
- https://git.kernel.org/stable/c/0b5394229ebae09afc07aabccb5ffd705ffd250e
- https://git.kernel.org/stable/c/25174d91e4a32a24204060d283bd5fa6d0ddf133
- https://git.kernel.org/stable/c/61b91eb33a69c3be11b259c5ea484505cd79f883
- https://git.kernel.org/stable/c/bb20a2ae241be846bc3c11ea4b3a3c69e41d51f2
- https://git.kernel.org/stable/c/cc3cd130ecfb8b0ae52e235e487bae3f16a24a32
Modified: 2024-10-31
CVE-2022-49000
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in has_external_pci() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() before 'return true' to avoid reference count leak.
Modified: 2024-10-30
CVE-2022-49001
In the Linux kernel, the following vulnerability has been resolved: riscv: fix race when vmap stack overflow Currently, when detecting vmap stack overflow, riscv firstly switches to the so called shadow stack, then use this shadow stack to call the get_overflow_stack() to get the overflow stack. However, there's a race here if two or more harts use the same shadow stack at the same time. To solve this race, we introduce spin_shadow_stack atomic var, which will be swap between its own address and 0 in atomic way, when the var is set, it means the shadow_stack is being used; when the var is cleared, it means the shadow_stack isn't being used. [Palmer: Add AQ to the swap, and also some comments.]
Modified: 2024-10-25
CVE-2022-49002
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak.
- https://git.kernel.org/stable/c/2a8f7b90681472948de172dbbf5a54cd342870aa
- https://git.kernel.org/stable/c/4bedbbd782ebbe7287231fea862c158d4f08a9e3
- https://git.kernel.org/stable/c/71c4a621985fc051ab86d3a86c749069a993fcb2
- https://git.kernel.org/stable/c/876d7bfb89273997056220029ff12b1c2cc4691d
- https://git.kernel.org/stable/c/a5c65cd56aed027f8a97fda8b691caaeb66d115e
- https://git.kernel.org/stable/c/bdb613ef179ad4bb9d56a2533e9b30e434f1dfb7
- https://git.kernel.org/stable/c/cbdd83bd2fd67142b03ce9dbdd1eab322ff7321f
- https://git.kernel.org/stable/c/d47bc9d7bcdbb9adc9703513d964b514fee5b0bf
Modified: 2024-10-25
CVE-2022-49003
In the Linux kernel, the following vulnerability has been resolved: nvme: fix SRCU protection of nvme_ns_head list Walking the nvme_ns_head siblings list is protected by the head's srcu in nvme_ns_head_submit_bio() but not nvme_mpath_revalidate_paths(). Removing namespaces from the list also fails to synchronize the srcu. Concurrent scan work can therefore cause use-after-frees. Hold the head's srcu lock in nvme_mpath_revalidate_paths() and synchronize with the srcu, not the global RCU, in nvme_ns_remove(). Observed the following panic when making NVMe/RDMA connections with native multipath on the Rocky Linux 8.6 kernel (it seems the upstream kernel has the same race condition). Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx; computing capacity != get_capacity(ns->disk). Address 0x50 is dereferenced because ns->disk is NULL. The NULL disk appears to be the result of concurrent scan work freeing the namespace (note the log line in the middle of the panic). [37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [37314.206036] nvme0n3: detected capacity change from 0 to 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1 [37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018 [37314.299763] Workqueue: nvme-wq nvme_scan_work [nvme_core] [37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core] [37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Call Trace: [37315.828515] nvme_update_ns_info+0x1ac/0x250 [nvme_core] [37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [nvme_core] [37315.961871] ? __blk_mq_free_request+0x6b/0x90 [37316.015021] nvme_scan_work+0x151/0x240 [nvme_core] [37316.073371] process_one_work+0x1a7/0x360 [37316.121318] ? create_worker+0x1a0/0x1a0 [37316.168227] worker_thread+0x30/0x390 [37316.212024] ? create_worker+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? set_kthread_struct+0x50/0x50 [37316.347590] ret_from_fork+0x35/0x40 [37316.390360] Modules linked in: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc overlay nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me pcspkr ipmi_devintf mei lpc_ich wmi ipmi_msghandler acpi_power_meter ex ---truncated---
Modified: 2024-10-25
CVE-2022-49004
In the Linux kernel, the following vulnerability has been resolved: riscv: Sync efi page table's kernel mappings before switching The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic. Fix that by updating the efi kernel mappings before switching to the efi page table.
Modified: 2024-10-25
CVE-2022-49005
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Fix bounds check for _sx controls For _sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in snd_soc_put_volsw_sx() needs to just check against the maximum value.
- https://git.kernel.org/stable/c/325d94d16e3131b54bdf07356e4cd855e0d853fc
- https://git.kernel.org/stable/c/46bab25cc0230df60d1c02b651cc5640a14b08df
- https://git.kernel.org/stable/c/4a95a49f26308782b4056401989ecd7768fda8fa
- https://git.kernel.org/stable/c/698813ba8c580efb356ace8dbf55f61dac6063a8
- https://git.kernel.org/stable/c/73dce3c1d48c4662bdf3ccbde1492c2cb4bfd8ce
- https://git.kernel.org/stable/c/98b15c706644bebc19d2e77ccc360cc51444f6d0
- https://git.kernel.org/stable/c/b50c9641897274c3faef5f95ac852f54b94be2e8
- https://git.kernel.org/stable/c/e46adadf19248d59af3aa6bc52e09115bf479bf7
Modified: 2024-11-04
CVE-2022-49006
In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the "type" field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number. When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="��������������������������������������� ---truncated---
- https://git.kernel.org/stable/c/1603feac154ff38514e8354e3079a455eb4801e2
- https://git.kernel.org/stable/c/417d5ea6e735e5d88ffb6c436cf2938f3f476dd1
- https://git.kernel.org/stable/c/4313e5a613049dfc1819a6dfb5f94cf2caff9452
- https://git.kernel.org/stable/c/be111ebd8868d4b7c041cb3c6102e1ae27d6dc1d
- https://git.kernel.org/stable/c/c52d0c8c4f38f7580cff61c4dfe1034c580cedfd
Modified: 2024-10-25
CVE-2022-49007
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()
Syzbot reported a null-ptr-deref bug:
NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP
frequency < 30 seconds
general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 3603 Comm: segctord Not tainted
6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google
10/11/2022
RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0
fs/nilfs2/alloc.c:608
Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00
00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7
RSP: 0018:ffffc90003dff830 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d
RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010
RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f
R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158
R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004
FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0
Call Trace:
- https://git.kernel.org/stable/c/165c7a3b27a3857ebf57f626b9f38b48b6792e68
- https://git.kernel.org/stable/c/2f2c59506ae39496588ceb8b88bdbdbaed895d63
- https://git.kernel.org/stable/c/33021419fd81efd3d729a7f19341ba4b98fe66ce
- https://git.kernel.org/stable/c/381b84f60e549ea98cec4666c6c728b1b3318756
- https://git.kernel.org/stable/c/9a130b72e6bd1fb07fc3cde839dc6fb53da76f07
- https://git.kernel.org/stable/c/bc3fd3293887b4cf84a9109700faeb82de533c89
- https://git.kernel.org/stable/c/e858917ab785afe83c14f5ac141301216ccda847
- https://git.kernel.org/stable/c/f0a0ccda18d6fd826d7c7e7ad48a6ed61c20f8b4
Modified: 2024-10-24
CVE-2022-49010
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Check for null before removing sysfs attrs
If coretemp_add_core() gets an error then pdata->core_data[indx]
is already NULL and has been kfreed. Don't pass that to
sysfs_remove_group() as that will crash in sysfs_remove_group().
[Shortened for readability]
[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'
- https://git.kernel.org/stable/c/070d5ea4a0592a37ad96ce7f7b6b024f90bb009f
- https://git.kernel.org/stable/c/280110db1a7d62ad635b103bafc3ae96e8bef75c
- https://git.kernel.org/stable/c/7692700ac818866d138a8de555130a6e70e6ac16
- https://git.kernel.org/stable/c/89eecabe6a47403237f45aafd7d24f93cb973653
- https://git.kernel.org/stable/c/a89ff5f5cc64b9fe7a992cf56988fd36f56ca82a
- https://git.kernel.org/stable/c/ae6c8b6e5d5628df1c475c0a8fca1465e205c95b
- https://git.kernel.org/stable/c/f06e0cd01eab954bd5f2190c9faa79bb5357e05b
- https://git.kernel.org/stable/c/fb503d077ff7b43913503eaf72995d1239028b99
Modified: 2024-10-24
CVE-2022-49011
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it after using to avoid refcount leak.
- https://git.kernel.org/stable/c/0dd1da5a15eeecb2fe4cf131b3216fb455af783c
- https://git.kernel.org/stable/c/2f74cffc7c85f770b1b1833dccb03b8cde3be102
- https://git.kernel.org/stable/c/6e035d5a2a6b907cfce9a80c5f442c2e459cd34e
- https://git.kernel.org/stable/c/7dec14537c5906b8bf40fd6fd6d9c3850f8df11d
- https://git.kernel.org/stable/c/bb75a0d1223d43f97089841aecb28a9b4de687a9
- https://git.kernel.org/stable/c/c40db1e5f316792b557d2be37e447c20d9ac4635
- https://git.kernel.org/stable/c/ea5844f946b1ec5c0b7c115cd7684f34fd48021b
- https://git.kernel.org/stable/c/f598da27acbeee414679cacd14294db3e273e3d2
Modified: 2024-10-24
CVE-2022-49013
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix memory leak in sctp_stream_outq_migrate()
When sctp_stream_outq_migrate() is called to release stream out resources,
the memory pointed to by prio_head in stream out is not released.
The memory leak information is as follows:
unreferenced object 0xffff88801fe79f80 (size 64):
comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s)
hex dump (first 32 bytes):
80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................
90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................
backtrace:
[
- https://git.kernel.org/stable/c/0dfb9a566327182387c90100ea54d8426cee8c67
- https://git.kernel.org/stable/c/176ee6c673ccd118e9392fd2dbb165423bdb99ca
- https://git.kernel.org/stable/c/9ed7bfc79542119ac0a9e1ce8a2a5285e43433e9
- https://git.kernel.org/stable/c/a7555681e50bdebed2c40ff7404ee73c2e932993
- https://git.kernel.org/stable/c/fa20f88271259d42ebe66f0a8c4c20199e888c99
Modified: 2024-10-24
CVE-2022-49014
In the Linux kernel, the following vulnerability has been resolved:
net: tun: Fix use-after-free in tun_detach()
syzbot reported use-after-free in tun_detach() [1]. This causes call
trace like below:
==================================================================
BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673
CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
- https://git.kernel.org/stable/c/04b995e963229501401810dab89dc73e7f12d054
- https://git.kernel.org/stable/c/16c244bc65d1175775325ec0489a5a5c830e02c7
- https://git.kernel.org/stable/c/1f23f1890d91812c35d32eab1b49621b6d32dc7b
- https://git.kernel.org/stable/c/4cde8da2d814a3b7b176db81922d4ddaad7c0f0e
- https://git.kernel.org/stable/c/5daadc86f27ea4d691e2131c04310d0418c6cd12
- https://git.kernel.org/stable/c/5f442e1d403e0496bacb74a58e2be7f500695e6f
Modified: 2024-10-24
CVE-2022-49015
In the Linux kernel, the following vulnerability has been resolved: net: hsr: Fix potential use-after-free The skb is delivered to netif_rx() which may free it, after calling this, dereferencing skb may trigger use-after-free.
- https://git.kernel.org/stable/c/4b351609af4fdbc23f79ab2b12748f4403ea9af4
- https://git.kernel.org/stable/c/53a62c5efe91665f7a41fad0f888a96f94dc59eb
- https://git.kernel.org/stable/c/7ca81a161e406834a1fdc405fc83a572bd14b8d9
- https://git.kernel.org/stable/c/7e177d32442b7ed08a9fa61b61724abc548cb248
- https://git.kernel.org/stable/c/8393ce5040803666bfa26a3a7bf41e44fab0ace9
- https://git.kernel.org/stable/c/b35d899854d5d5d58eb7d7e7c0f61afc60d3a9e9
- https://git.kernel.org/stable/c/dca370e575d9b6c983f5015e8dc035e23e219ee6
- https://git.kernel.org/stable/c/f3add2b8cf620966de3ebfa07679ca12d33ec26f
Modified: 2024-10-24
CVE-2022-49016
In the Linux kernel, the following vulnerability has been resolved: net: mdiobus: fix unbalanced node reference count I got the following report while doing device(mscc-miim) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0 If the 'fwnode' is not an acpi node, the refcount is get in fwnode_mdiobus_phy_device_register(), but it has never been put when the device is freed in the normal path. So call fwnode_handle_put() in phy_device_release() to avoid leak. If it's an acpi node, it has never been get, but it's put in the error path, so call fwnode_handle_get() before phy_device_register() to keep get/put operation balanced.
Modified: 2024-10-24
CVE-2022-49017
In the Linux kernel, the following vulnerability has been resolved:
tipc: re-fetch skb cb after tipc_msg_validate
As the call trace shows, the original skb was freed in tipc_msg_validate(),
and dereferencing the old skb cb would cause an use-after-free crash.
BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
Call Trace:
Modified: 2024-10-24
CVE-2022-49019
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv->rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv->rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/45752af0247589e6d3dede577415bfe117b4392c
- https://git.kernel.org/stable/c/80e82f7b440b65cf131dce10f487dc73a7046e6b
- https://git.kernel.org/stable/c/910c0264b64ef2dad8887714a7c56c93e39a0ed3
- https://git.kernel.org/stable/c/9256db4e45e8b497b0e993cc3ed4ad08eb2389b6
- https://git.kernel.org/stable/c/9c584d6d9cfb935dce8fc81a4c26debac0a3049b
Modified: 2024-10-24
CVE-2022-49020
In the Linux kernel, the following vulnerability has been resolved: net/9p: Fix a potential socket leak in p9_socket_open Both p9_fd_create_tcp() and p9_fd_create_unix() will call p9_socket_open(). If the creation of p9_trans_fd fails, p9_fd_create_tcp() and p9_fd_create_unix() will return an error directly instead of releasing the cscoket, which will result in a socket leak. This patch adds sock_release() to fix the leak issue.
- https://git.kernel.org/stable/c/0396227f4daf4792a6a8aaa3b7771dc25c4cd443
- https://git.kernel.org/stable/c/2d24d91b9f44620824fc37b766f7cae00ca32748
- https://git.kernel.org/stable/c/8782b32ef867de7981bbe9e86ecb90e92e8780bd
- https://git.kernel.org/stable/c/8b14bd0b500aec1458b51cb621c8e5fab3304260
- https://git.kernel.org/stable/c/aa08323fe18cb7cf95317ffa2d54ca1de8e74ebd
- https://git.kernel.org/stable/c/dcc14cfd7debe11b825cb077e75d91d2575b4cb8
- https://git.kernel.org/stable/c/ded893965b895b2dccd3d1436d8d3daffa23ea64
- https://git.kernel.org/stable/c/e01c1542379fb395e7da53706df598f38905dfbf
Modified: 2024-10-24
CVE-2022-49021
In the Linux kernel, the following vulnerability has been resolved:
net: phy: fix null-ptr-deref while probe() failed
I got a null-ptr-deref report as following when doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
- https://git.kernel.org/stable/c/0744c7be4de564db03e24527b2e096b7e0e20972
- https://git.kernel.org/stable/c/369eb2c9f1f72adbe91e0ea8efb130f0a2ba11a6
- https://git.kernel.org/stable/c/3e21f85d87c836462bb52ef2078ea561260935c1
- https://git.kernel.org/stable/c/51d7f6b20fae8bae64ad1136f1e30d1fd5ba78f7
- https://git.kernel.org/stable/c/7730904f50c7187dd16c76949efb56b5fb55cd57
- https://git.kernel.org/stable/c/8aaafe0f71314f46a066382a047ba8bb3840d273
- https://git.kernel.org/stable/c/eaa5722549ac2604ffa56c2e946acc83226f130c
- https://git.kernel.org/stable/c/fe6bc99c27c21348f548966118867ed26a9a372c
Modified: 2024-10-24
CVE-2022-49022
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac8021: fix possible oob access in ieee80211_get_rate_duration
Fix possible out-of-bound access in ieee80211_get_rate_duration routine
as reported by the following UBSAN report:
UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47
index 15 is out of range for type 'u16 [12]'
CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic
Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017
Workqueue: mt76 mt76u_tx_status_data [mt76_usb]
Call Trace:
Modified: 2024-10-24
CVE-2022-49023
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix buffer overflow in elem comparison For vendor elements, the code here assumes that 5 octets are present without checking. Since the element itself is already checked to fit, we only need to check the length.
- https://git.kernel.org/stable/c/391cb872553627bdcf236c03ee7d5adb275e37e1
- https://git.kernel.org/stable/c/88a6fe3707888bd1893e9741157a7035c4159ab6
- https://git.kernel.org/stable/c/9e6b79a3cd17620d467311b30d56f2648f6880aa
- https://git.kernel.org/stable/c/9f16b5c82a025cd4c864737409234ddc44fb166a
- https://git.kernel.org/stable/c/f5c2ec288a865dbe3706b09bed12302e9f6d696b
Modified: 2024-10-24
CVE-2022-49024
In the Linux kernel, the following vulnerability has been resolved: can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods In m_can_pci_remove() and error handling path of m_can_pci_probe(), m_can_class_free_dev() should be called to free resource allocated by m_can_class_allocate_dev(), otherwise there will be memleak.
Modified: 2024-10-24
CVE-2022-49025
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free when reverting termination table When having multiple dests with termination tables and second one or afterwards fails the driver reverts usage of term tables but doesn't reset the assignment in attr->dests[num_vport_dests].termtbl which case a use-after-free when releasing the rule. Fix by resetting the assignment of termtbl to null.
- https://git.kernel.org/stable/c/0a2d73a77060c3cbdc6e801cd5d979d674cd404b
- https://git.kernel.org/stable/c/0d2f9d95d9fbe993f3c4bafb87d59897b0325aff
- https://git.kernel.org/stable/c/372eb550faa0757349040fd43f59483cbfdb2c0b
- https://git.kernel.org/stable/c/52c795af04441d76f565c4634f893e5b553df2ae
- https://git.kernel.org/stable/c/e6d2d26a49c3a9cd46b232975e45236304810904
Modified: 2024-10-24
CVE-2022-49026
In the Linux kernel, the following vulnerability has been resolved: e100: Fix possible use after free in e100_xmit_prepare In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will resend the skb. But the skb is already freed, which will cause UAF bug when the upper layer resends the skb. Remove the harmful free.
Modified: 2024-10-24
CVE-2022-49027
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix error handling in iavf_init_module() The iavf_init_module() won't destroy workqueue when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak")
Modified: 2024-10-24
CVE-2022-49028
In the Linux kernel, the following vulnerability has been resolved: ixgbevf: Fix resource leak in ixgbevf_init_module() ixgbevf_init_module() won't destroy the workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Add destroy_workqueue() in fail path to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak")
Modified: 2024-10-24
CVE-2022-49029
In the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data->list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().
- https://git.kernel.org/stable/c/24b9633f7db7f4809be7053df1d2e117e7c2de10
- https://git.kernel.org/stable/c/45f6e81863747c0d7bc6a95ec51129900e71467a
- https://git.kernel.org/stable/c/798198273bf86673b970b51acdb35e57f42b3fcb
- https://git.kernel.org/stable/c/7b2b67fe1339389e0bf3c37c7a677a004ac0e4e3
- https://git.kernel.org/stable/c/90907cd4d11351ff76c9a447bcb5db0e264c47cd
- https://git.kernel.org/stable/c/e2a87785aab0dac190ac89be6a9ba955e2c634f2
- https://git.kernel.org/stable/c/e65cfd1f9cd27d9c27ee5cb88128a9f79f25d863
- https://git.kernel.org/stable/c/f2a13196ad41c6c2ab058279dffe6c97292e753a
Modified: 2024-10-24
CVE-2022-49030
In the Linux kernel, the following vulnerability has been resolved: libbpf: Handle size overflow for ringbuf mmap The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t. So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap.
Modified: 2024-10-24
CVE-2022-49031
In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4403: Fix oob read in afe4403_read_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279 Call Trace: afe4403_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4403_channel_leds+0x18/0xffffffffffffe9e0 This issue can be reproduced by singe command: $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw The array size of afe4403_channel_leds is less than channels, so access with chan->address cause OOB read in afe4403_read_raw. Fix it by moving access before use it.
- https://git.kernel.org/stable/c/06c6ce21cec77dfa860d57e7a006000a57812efb
- https://git.kernel.org/stable/c/2d6a437064ffbe685c67ddb16dfc0946074c6c3f
- https://git.kernel.org/stable/c/58143c1ed5882c138a3cd2251a336fc8755f23d9
- https://git.kernel.org/stable/c/726fa3e4ab97dcff1c745bdc4fb137366cb8d3df
- https://git.kernel.org/stable/c/98afcb5f3be645d330c74c5194ba0d80e26f95e0
- https://git.kernel.org/stable/c/b1756af172fb80a3edc143772d49e166ec691b6c
- https://git.kernel.org/stable/c/c9268df36818ee4eaaaeadc80009b442a5ca69c9
- https://git.kernel.org/stable/c/e7e76a77aabef8989cbc0a8417af1aa040620867
Modified: 2024-10-24
CVE-2022-49032
In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278 Call Trace: afe4404_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 This issue can be reproduce by singe command: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan->address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them.
- https://git.kernel.org/stable/c/113c08030a89aaf406f8a1d4549d758a67c2afba
- https://git.kernel.org/stable/c/3f566b626029ca8598d48e5074e56bb37399ca1b
- https://git.kernel.org/stable/c/5eb114f55b37dbc0487aa9c1913b81bb7837f1c4
- https://git.kernel.org/stable/c/68de7da092f38395dde523f2e5db26eba6c23e28
- https://git.kernel.org/stable/c/d45d9f45e7b1365fd0d9bf14680d6d5082a590d1
- https://git.kernel.org/stable/c/f5575041ec15310bdc50c42b8b22118cc900226e
- https://git.kernel.org/stable/c/f7419fc42afc035f6b29ce713e17dcd2000c833f
- https://git.kernel.org/stable/c/fc92d9e3de0b2d30a3ccc08048a5fad533e4672b
Modified: 2024-10-30
CVE-2022-49033
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()
Syzkaller reported BUG as follows:
BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:274
Call Trace:
- https://git.kernel.org/stable/c/01d7c41eac9129fba80d8aed0060caab4a7dbe09
- https://git.kernel.org/stable/c/044da1a371a0da579e805e89c96865f62d8f6f69
- https://git.kernel.org/stable/c/3c98e91be6aea4c7acf09da6eb0c107ea9186bb5
- https://git.kernel.org/stable/c/588ae4fdd8b11788a797776b10d6c44ae12bc133
- https://git.kernel.org/stable/c/89840b12c8fad7200eb6478525c13261512c01be
- https://git.kernel.org/stable/c/8eb912af525042a7365295eb62f6d5270c2a6462
- https://git.kernel.org/stable/c/f4b930a1602b05e77fee31f9616599b25e910a86
- https://git.kernel.org/stable/c/f7e942b5bb35d8e3af54053d19a6bf04143a3955
Modified: 2025-10-01
CVE-2022-49035
In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case.
- https://git.kernel.org/stable/c/1609231f86760c1f6a429de7913dd795b9faa08c
- https://git.kernel.org/stable/c/2654e785bd4aa2439cdffbe7dc1ea30a0eddbfe4
- https://git.kernel.org/stable/c/4a449430ecfb199b99ba58af63c467eb53500b39
- https://git.kernel.org/stable/c/7ccb40f26cbefa1c6dfd3418bea54c9518cdbd8a
- https://git.kernel.org/stable/c/93f65ce036863893c164ca410938e0968964b26c
- https://git.kernel.org/stable/c/a2728bf9b6c65e46468c763e3dab7e04839d4e11
- https://git.kernel.org/stable/c/cbfa26936f318b16ccf9ca31b8e8b30c0dc087bd
- https://git.kernel.org/stable/c/fc0f76dd5f116fa9291327024dda392f8b4e849c
Modified: 2025-10-01
CVE-2022-49139
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL.
- https://git.kernel.org/stable/c/0f9db1209f59844839175b5b907d3778cafde93d
- https://git.kernel.org/stable/c/1c1291a84e94f6501644634c97544bb8291e9a1a
- https://git.kernel.org/stable/c/3afee2118132e93e5f6fa636dfde86201a860ab3
- https://git.kernel.org/stable/c/c1aa0dd52db4ce888be0bd820c3fa918d350ca0b
- https://git.kernel.org/stable/c/f61c23e73dc653b957781066abfa8105c3fa3f5b
Modified: 2025-10-21
CVE-2022-49513
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: governor: Use kobject release() method to free dbs_data
The struct dbs_data embeds a struct gov_attr_set and
the struct gov_attr_set embeds a kobject. Since every kobject must have
a release() method and we can't use kfree() to free it directly,
so introduce cpufreq_dbs_data_release() to release the dbs_data via
the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34
WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
Modules linked in:
CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536
Hardware name: Marvell OcteonTX CN96XX board (DT)
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : debug_print_object+0xb8/0x100
lr : debug_print_object+0xb8/0x100
sp : ffff80001dfcf9a0
x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000
x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210
x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118
x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000
x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8
x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14
x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0
x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001
x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040
Call trace:
debug_print_object+0xb8/0x100
__debug_check_no_obj_freed+0x1d0/0x25c
debug_check_no_obj_freed+0x24/0xa0
kfree+0x11c/0x440
cpufreq_dbs_governor_exit+0xa8/0xac
cpufreq_exit_governor+0x44/0x90
cpufreq_set_policy+0x29c/0x570
store_scaling_governor+0x110/0x154
store+0xb0/0xe0
sysfs_kf_write+0x58/0x84
kernfs_fop_write_iter+0x12c/0x1c0
new_sync_write+0xf0/0x18c
vfs_write+0x1cc/0x220
ksys_write+0x74/0x100
__arm64_sys_write+0x28/0x3c
invoke_syscall.constprop.0+0x58/0xf0
do_el0_svc+0x70/0x170
el0_svc+0x54/0x190
el0t_64_sync_handler+0xa4/0x130
el0t_64_sync+0x1a0/0x1a4
irq event stamp: 189006
hardirqs last enabled at (189005): [
Modified: 2025-10-01
CVE-2022-49746
In the Linux kernel, the following vulnerability has been resolved: dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init If the function sdma_load_context() fails, the sdma_desc will be freed, but the allocated desc->bd is forgot to be freed. We already met the sdma_load_context() failure case and the log as below: [ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready ... In this case, the desc->bd will not be freed without this change.
- https://git.kernel.org/stable/c/1417f59ac0b02130ee56c0c50794b9b257be3d17
- https://git.kernel.org/stable/c/43acd767bd90c5d4172ce7fee5d9007a9a08dea9
- https://git.kernel.org/stable/c/80ee99e52936b2c04cc37b17a14b2ae2f9d282ac
- https://git.kernel.org/stable/c/bd0050b7ffa87c7b260d563646af612f4112a778
- https://git.kernel.org/stable/c/ce4745a6b8016fae74c95dcd457d4ceef7d98af1
- https://git.kernel.org/stable/c/dbe634ce824329d8f14079c3e9f8f11670894bec
Modified: 2025-10-29
CVE-2022-49747
In the Linux kernel, the following vulnerability has been resolved: erofs/zmap.c: Fix incorrect offset calculation Effective offset to add to length was being incorrectly calculated, which resulted in iomap->length being set to 0, triggering a WARN_ON in iomap_iter_done(). Fix that, and describe it in comments. This was reported as a crash by syzbot under an issue about a warning encountered in iomap_iter_done(), but unrelated to erofs. C reproducer: https://syzkaller.appspot.com/text?tag=ReproC&x=1037a6b2880000 Kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=e2021a61197ebe02 Dashboard link: https://syzkaller.appspot.com/bug?extid=a8e049cd3abd342936b6
Modified: 2025-10-01
CVE-2022-49748
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: fix potential integer overflow on shift of a int The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then passed as a 64 bit function argument. In the case where i is 32 or more this can lead to an overflow. Avoid this by shifting using the BIT_ULL macro instead.
- https://git.kernel.org/stable/c/08245672cdc6505550d1a5020603b0a8d4a6dcc7
- https://git.kernel.org/stable/c/14cc13e433e1067557435b1adbf05608d7d47a93
- https://git.kernel.org/stable/c/a4d01fb87ece45d4164fd725890211ccf9a307a9
- https://git.kernel.org/stable/c/f84c9b72fb200633774704d8020f769c88a4b249
- https://git.kernel.org/stable/c/fbf7b0e4cef3b5470b610f14fb9faa5ee7f63954
Modified: 2025-10-01
CVE-2022-49749
In the Linux kernel, the following vulnerability has been resolved: i2c: designware: use casting of u64 in clock multiplication to avoid overflow In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow by depending on the values of the given parameters including the ic_clk. For example in our use case where ic_clk is larger than one million, multiplication of ic_clk * 4700 will result in 32 bit overflow. Add cast of u64 to the calculation to avoid multiplication overflow, and use the corresponding define for divide.
Modified: 2025-10-01
CVE-2022-49751
In the Linux kernel, the following vulnerability has been resolved: w1: fix WARNING after calling w1_process() I got the following WARNING message while removing driver(ds2482): ------------[ cut here ]------------ do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire] WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0 CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307 RIP: 0010:__might_sleep+0x98/0xa0 Call Trace: exit_signals+0x6c/0x550 do_exit+0x2b4/0x17e0 kthread_exit+0x52/0x60 kthread+0x16d/0x1e0 ret_from_fork+0x1f/0x30 The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(), set it to TASK_RUNNING when it breaks out of the loop to avoid the warning.
- https://git.kernel.org/stable/c/190b5c3bbd5df685bb1063bda048831d72b8f1d4
- https://git.kernel.org/stable/c/216f35db6ec6a667cd9db4838d657c1d2f4684da
- https://git.kernel.org/stable/c/276052159ba94d4d9f5b453fb4707d6798c6b845
- https://git.kernel.org/stable/c/36225a7c72e9e3e1ce4001b6ce72849f5c9a2d3b
- https://git.kernel.org/stable/c/89c62cee5d4d65ac75d99b5f986f7f94290e888f
- https://git.kernel.org/stable/c/bccd6df4c177b1ad766f16565ccc298653d027d0
- https://git.kernel.org/stable/c/cfc7462ff824ed6718ed0272ee9aae88e20d469a
Modified: 2026-04-18
CVE-2022-49752
In the Linux kernel, the following vulnerability has been resolved: device property: fix of node refcount leak in fwnode_graph_get_next_endpoint() The 'parent' returned by fwnode_graph_get_port_parent() with refcount incremented when 'prev' is not NULL, it needs be put when finish using it. Because the parent is const, introduce a new variable to store the returned fwnode, then put it before returning from fwnode_graph_get_next_endpoint().
Modified: 2025-04-01
CVE-2022-49753
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: Fix double increment of client_count in dma_chan_get()
The first time dma_chan_get() is called for a channel the channel
client_count is incorrectly incremented twice for public channels,
first in balance_ref_count(), and again prior to returning. This
results in an incorrect client count which will lead to the
channel resources not being freed when they should be. A simple
test of repeated module load and unload of async_tx on a Dell
Power Edge R7425 also shows this resulting in a kref underflow
warning.
[ 124.329662] async_tx: api initialized (async)
[ 129.000627] async_tx: api initialized (async)
[ 130.047839] ------------[ cut here ]------------
[ 130.052472] refcount_t: underflow; use-after-free.
[ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28
refcount_warn_saturate+0xba/0x110
[ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr
intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm
mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si
syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops
k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat
fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul
libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas
i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash
dm_log dm_mod [last unloaded: async_tx]
[ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not
tainted 5.14.0-185.el9.x86_64 #1
[ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS
1.18.0 01/17/2022
[ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110
[ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d
26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a
bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff
48 c7
[ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286
[ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000
[ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0
[ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff
[ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970
[ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000)
knlGS:0000000000000000
[ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0
[ 130.219729] Call Trace:
[ 130.222192]
- https://git.kernel.org/stable/c/142d644fd2cc059ffa042fbfb68e766433ef3afd
- https://git.kernel.org/stable/c/18dd3b30d4c7e8440c63118c7a7b687372b9567f
- https://git.kernel.org/stable/c/1b409e14b4b7af034e0450f95c165b6c5c87dbc1
- https://git.kernel.org/stable/c/42ecd72f02cd657b00b559621e7ef7d2c4d3e5f1
- https://git.kernel.org/stable/c/71c601965532c38030133535f7cd93c1efa75af1
- https://git.kernel.org/stable/c/c6221afe573413fd2981e291f7df4a58283e0654
- https://git.kernel.org/stable/c/f3dc1b3b4750851a94212dba249703dd0e50bb20
Modified: 2025-04-01
CVE-2022-49755
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait While performing fast composition switch, there is a possibility that the process of ffs_ep0_write/ffs_ep0_read get into a race condition due to ep0req being freed up from functionfs_unbind. Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't bounded so it can go ahead and mark the ep0req to NULL, and since there is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free. Fix this by making a serialized execution between the two functions using a mutex_lock(ffs->mutex).
- https://git.kernel.org/stable/c/6a19da111057f69214b97c62fb0ac59023970850
- https://git.kernel.org/stable/c/6aee197b7fbcd61596a78b47d553f2f99111f217
- https://git.kernel.org/stable/c/6dd9ea05534f323668db94fcc2726c7a84547e78
- https://git.kernel.org/stable/c/a8d40942df074f4ebcb9bd3413596d92f323b064
- https://git.kernel.org/stable/c/ae8e136bcaae96163b5821984de1036efc9abb1a
- https://git.kernel.org/stable/c/e9036e951f93fb8d7b5e9d6e2c7f94a4da312ae4
- https://git.kernel.org/stable/c/facf353c9e8d7885b686d9a4b173d4e0af6441d2
Modified: 2025-10-01
CVE-2022-49757
In the Linux kernel, the following vulnerability has been resolved: EDAC/highbank: Fix memory leak in highbank_mc_probe() When devres_open_group() fails, it returns -ENOMEM without freeing memory allocated by edac_mc_alloc(). Call edac_mc_free() on the error handling path to avoid a memory leak. [ bp: Massage commit message. ]
- https://git.kernel.org/stable/c/0db40e23b56d217eebd385bebb64057ef764b2c7
- https://git.kernel.org/stable/c/329fbd260352a7b9a83781d8b8bd96f95844a51f
- https://git.kernel.org/stable/c/8d23f5d25264beb223ee79cdb530b88c237719fc
- https://git.kernel.org/stable/c/b7863ef8a8f0fee96b4eb41211f4918c0e047253
- https://git.kernel.org/stable/c/caffa7fed1397d1395052272c93900176de86557
- https://git.kernel.org/stable/c/e7a293658c20a7945014570e1921bf7d25d68a36
- https://git.kernel.org/stable/c/f1b3e23ed8df87d779ee86ac37f379e79a24169a
Modified: 2025-10-01
CVE-2022-49758
In the Linux kernel, the following vulnerability has been resolved: reset: uniphier-glue: Fix possible null-ptr-deref It will cause null-ptr-deref when resource_size(res) invoked, if platform_get_resource() returns NULL.
Modified: 2025-04-01
CVE-2022-49761
In the Linux kernel, the following vulnerability has been resolved: btrfs: always report error in run_one_delayed_ref() Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but if end users hit such problem, there will be no chance that btrfs_debug() is enabled. This can lead to very little useful info for debugging. This patch will: - Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod - Replace the btrfs_debug() with btrfs_err() - Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller. This error should only be triggered at most once. As if run_one_delayed_ref() failed, we trigger the error message, then causing the call chain to error out: btrfs_run_delayed_refs() `- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref() And we will abort the current transaction in btrfs_run_delayed_refs(). If we have to run delayed refs for the abort transaction, run_one_delayed_ref() will just cleanup the refs and do nothing, thus no new error messages would be output.
Modified: 2025-11-06
CVE-2022-49762
In the Linux kernel, the following vulnerability has been resolved: ntfs: check overflow when iterating ATTR_RECORDs Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). Because the ATTR_RECORDs are next to each other, kernel can get the next ATTR_RECORD from end address of current ATTR_RECORD, through current ATTR_RECORD length field. The problem is that during iteration, when kernel calculates the end address of current ATTR_RECORD, kernel may trigger an integer overflow bug in executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. This may wrap, leading to a forever iteration on 32bit systems. This patch solves it by adding some checks on calculating end address of current ATTR_RECORD during iteration.
- https://git.kernel.org/stable/c/45683723f6b53e39e8a4cec0894e61fd6ec71989
- https://git.kernel.org/stable/c/5559eb5809353a83a40a1e4e7f066431c7b83020
- https://git.kernel.org/stable/c/63095f4f3af59322bea984a6ae44337439348fe0
- https://git.kernel.org/stable/c/785b2af9654b8beac55644e36da0085c5d776361
- https://git.kernel.org/stable/c/86f36de14dce5802856bb7a5921d74439db00b64
- https://git.kernel.org/stable/c/957732a09c3828267c2819d31c425aa793dd475b
- https://git.kernel.org/stable/c/b612f924f296408d7d02fb4cd01218afd4ed7184
- https://git.kernel.org/stable/c/b63ddb3ba61e2d3539f87e095c881e552bc45dab
Modified: 2025-11-06
CVE-2022-49763
In the Linux kernel, the following vulnerability has been resolved:
ntfs: fix use-after-free in ntfs_attr_find()
Patch series "ntfs: fix bugs about Attribute", v2.
This patchset fixes three bugs relative to Attribute in record:
Patch 1 adds a sanity check to ensure that, attrs_offset field in first
mft record loading from disk is within bounds.
Patch 2 moves the ATTR_RECORD's bounds checking earlier, to avoid
dereferencing ATTR_RECORD before checking this ATTR_RECORD is within
bounds.
Patch 3 adds an overflow checking to avoid possible forever loop in
ntfs_attr_find().
Without patch 1 and patch 2, the kernel triggersa KASAN use-after-free
detection as reported by Syzkaller.
Although one of patch 1 or patch 2 can fix this, we still need both of
them. Because patch 1 fixes the root cause, and patch 2 not only fixes
the direct cause, but also fixes the potential out-of-bounds bug.
This patch (of 3):
Syzkaller reported use-after-free read as follows:
==================================================================
BUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597
Read of size 2 at addr ffff88807e352009 by task syz-executor153/3607
[...]
Call Trace:
- https://git.kernel.org/stable/c/266bd5306286316758e6246ea0345133427b0f62
- https://git.kernel.org/stable/c/4863f815463034f588a035cfd99cdca97a4f1069
- https://git.kernel.org/stable/c/5330c423b86263ac7883fef0260b9e2229cb531e
- https://git.kernel.org/stable/c/79f3ac7dcd12c05b7539239a4c6fa229a50d786c
- https://git.kernel.org/stable/c/b825bfbbaafbe8da2037e3a778ad660c59f9e054
- https://git.kernel.org/stable/c/d0006d739738a658a9c29b438444259d9f71dfa0
- https://git.kernel.org/stable/c/d85a1bec8e8d552ab13163ca1874dcd82f3d1550
- https://git.kernel.org/stable/c/fb2004bafd1932e08d21ca604ee5844f2b7f212d
Modified: 2025-11-06
CVE-2022-49765
In the Linux kernel, the following vulnerability has been resolved: net/9p: use a dedicated spinlock for trans_fd Shamelessly copying the explanation from Tetsuo Handa's suggested patch[1] (slightly reworded): syzbot is reporting inconsistent lock state in p9_req_put()[2], for p9_tag_remove() from p9_req_put() from IRQ context is using spin_lock_irqsave() on "struct p9_client"->lock but trans_fd (not from IRQ context) is using spin_lock(). Since the locks actually protect different things in client.c and in trans_fd.c, just replace trans_fd.c's lock by a new one specific to the transport (client.c's protect the idr for fid/tag allocations, while trans_fd.c's protects its own req list and request status field that acts as the transport's state machine)
Modified: 2025-11-06
CVE-2022-49767
In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: always use O_NONBLOCK read/write syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is failing to interrupt already started kernel_read() from p9_fd_read() from p9_read_work() and/or kernel_write() from p9_fd_write() from p9_write_work() requests. Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open() does not set O_NONBLOCK flag, but pipe blocks unless signal is pending, p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when the file descriptor refers to a pipe. In other words, pipe file descriptor needs to be handled as if socket file descriptor. We somehow need to interrupt kernel_read()/kernel_write() on pipes. A minimal change, which this patch is doing, is to set O_NONBLOCK flag from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing of regular files. But this approach changes O_NONBLOCK flag on userspace- supplied file descriptors (which might break userspace programs), and O_NONBLOCK flag could be changed by userspace. It would be possible to set O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still remains small race window for clearing O_NONBLOCK flag. If we don't want to manipulate O_NONBLOCK flag, we might be able to surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING) and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are processed by kernel threads which process global system_wq workqueue, signals could not be delivered from remote threads when p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be needed if we count on signals for making kernel_read()/kernel_write() non-blocking. [Dominique: add comment at Christian's suggestion]
- https://git.kernel.org/stable/c/0b5e6bd72b8171364616841603a70e4ba9837063
- https://git.kernel.org/stable/c/0e07032b4b4724b8ad1003698cb81083c1818999
- https://git.kernel.org/stable/c/5af16182c5639349415118e9e9aecd8355f7a08b
- https://git.kernel.org/stable/c/7abf40f06a76c0dff42eada10597917e9776fbd4
- https://git.kernel.org/stable/c/9f8554615df668e4bf83294633ee9d232b28ce45
- https://git.kernel.org/stable/c/a8e2fc8f7b41fa9d9ca5f624f4e4d34fce5b40a9
- https://git.kernel.org/stable/c/b1ad04da7fe4515e2ce2d5f2dcab3b5b6d45614b
- https://git.kernel.org/stable/c/ef575281b21e9a34dfae544a187c6aac2ae424a9
Modified: 2025-11-06
CVE-2022-49768
In the Linux kernel, the following vulnerability has been resolved: 9p: trans_fd/p9_conn_cancel: drop client lock earlier syzbot reported a double-lock here and we no longer need this lock after requests have been moved off to local list: just drop the lock earlier.
- https://git.kernel.org/stable/c/52f1c45dde9136f964d63a77d19826c8a74e2c7f
- https://git.kernel.org/stable/c/612c977f5d481f551d03d83d0aef588845c1300c
- https://git.kernel.org/stable/c/82825dbf393f7c7979d462f9609a15bde8092b3f
- https://git.kernel.org/stable/c/96760723aae1b45f733f702abb4333137143909f
- https://git.kernel.org/stable/c/a4f1a01b2e81378fce9ca528d4d8a049e4b58fcd
- https://git.kernel.org/stable/c/e3031280fe4eaf61a09e60823331f81f321be8e1
- https://git.kernel.org/stable/c/f14858bc77c567e089965962877ee726ffad0556
- https://git.kernel.org/stable/c/fec1406f5e7ab20b71f6d231792b0040e3300aaf
Modified: 2025-11-06
CVE-2022-49769
In the Linux kernel, the following vulnerability has been resolved: gfs2: Check sb_bsize_shift after reading superblock Fuzzers like to scribble over sb_bsize_shift but in reality it's very unlikely that this field would be corrupted on its own. Nevertheless it should be checked to avoid the possibility of messy mount errors due to bad calculations. It's always a fixed value based on the block size so we can just check that it's the expected value. Tested with: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; do gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb mount /dev/vdb /mnt/test && umount /mnt/test done Before this patch we get a withdraw after [ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block [ 76.413681] bh = 19 (type: exp=5, found=4) [ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492 and with UBSAN configured we also get complaints like [ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19 [ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int' After the patch, these complaints don't appear, mount fails immediately and we get an explanation in dmesg.
- https://git.kernel.org/stable/c/15c83fa0fd659dd9fbdc940a560b61236e876a80
- https://git.kernel.org/stable/c/16670534c7cff1acd918a6a5ec751b14e7436b76
- https://git.kernel.org/stable/c/1ad197097343568066a8ffaa27ee7d0ae6d9f476
- https://git.kernel.org/stable/c/28275a7c84d21c55ab3282d897f284d8d527173c
- https://git.kernel.org/stable/c/5fa30be7ba81191b0a0c7239a89befc0c94286d5
- https://git.kernel.org/stable/c/670f8ce56dd0632dc29a0322e188cc73ce3c6b92
- https://git.kernel.org/stable/c/8b6534c9ae9dba5489703a19d8ba6c8f2cfa33c2
- https://git.kernel.org/stable/c/d6b1e8ea6f3418c3b461ad5a35cdc93c996b2c87
Modified: 2025-11-06
CVE-2022-49770
In the Linux kernel, the following vulnerability has been resolved: ceph: avoid putting the realm twice when decoding snaps fails When decoding the snaps fails it maybe leaving the 'first_realm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUG_ON, etc issues.
- https://git.kernel.org/stable/c/044bc6d3c2c0e9090b0841e7b723875756534b45
- https://git.kernel.org/stable/c/274e4c79a3a2a24fba7cfe0e41113f1138785c37
- https://git.kernel.org/stable/c/2f6e2de3a5289004650118b61f138fe7c28e1905
- https://git.kernel.org/stable/c/51884d153f7ec85e18d607b2467820a90e0f4359
- https://git.kernel.org/stable/c/cb7495fe957526555782ce0723f79ce92a6db22e
- https://git.kernel.org/stable/c/fd879c83e87735ab8f00ef7755752cf0cbae24b2
Modified: 2025-11-07
CVE-2022-49771
In the Linux kernel, the following vulnerability has been resolved: dm ioctl: fix misbehavior if list_versions races with module loading __list_versions will first estimate the required space using the "dm_target_iterate(list_version_get_needed, &needed)" call and then will fill the space using the "dm_target_iterate(list_version_get_info, &iter_info)" call. Each of these calls locks the targets using the "down_read(&_lock)" and "up_read(&_lock)" calls, however between the first and second "dm_target_iterate" there is no lock held and the target modules can be loaded at this point, so the second "dm_target_iterate" call may need more space than what was the first "dm_target_iterate" returned. The code tries to handle this overflow (see the beginning of list_version_get_info), however this handling is incorrect. The code sets "param->data_size = param->data_start + needed" and "iter_info.end = (char *)vers+len" - "needed" is the size returned by the first dm_target_iterate call; "len" is the size of the buffer allocated by userspace. "len" may be greater than "needed"; in this case, the code will write up to "len" bytes into the buffer, however param->data_size is set to "needed", so it may write data past the param->data_size value. The ioctl interface copies only up to param->data_size into userspace, thus part of the result will be truncated. Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this guarantees that the second "dm_target_iterate" call will write only up to the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry. Note that there is also a bug in list_version_get_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".
- https://git.kernel.org/stable/c/0c8d4112df329bf3dfbf27693f918c3b08676538
- https://git.kernel.org/stable/c/3a1c35d72dc0b34d1e746ed705790c0f630aa427
- https://git.kernel.org/stable/c/4fe1ec995483737f3d2a14c3fe1d8fe634972979
- https://git.kernel.org/stable/c/5398b8e275bf81a2517b327d216c0f37ac9ac5ae
- https://git.kernel.org/stable/c/6a818db0d5aecf80d4ba9e10ac153f60adc629ca
- https://git.kernel.org/stable/c/6ffce7a92ef5c68f7e5d6f4d722c2f96280c064b
- https://git.kernel.org/stable/c/b545c0e1e4094d4de2bdfe9a3823f9154b0c0005
- https://git.kernel.org/stable/c/f59f5a269ca5e43c567aca7f1f52500a0186e9b7
Modified: 2025-12-23
CVE-2022-49772
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open() snd_usbmidi_output_open() has a check of the NULL port with snd_BUG_ON(). snd_BUG_ON() was used as this shouldn't have happened, but in reality, the NULL port may be seen when the device gives an invalid endpoint setup at the descriptor, hence the driver skips the allocation. That is, the check itself is valid and snd_BUG_ON() should be dropped from there. Otherwise it's confusing as if it were a real bug, as recently syzbot stumbled on it.
- https://git.kernel.org/stable/c/00f5f1bbf815a39e9eecb468d12ca55d3360eb10
- https://git.kernel.org/stable/c/02b94885b2fdf1808b1874e009bfb90753f8f4db
- https://git.kernel.org/stable/c/a80369c8ca50bc885d14386087a834659ec54a54
- https://git.kernel.org/stable/c/ad72c3c3f6eb81d2cb189ec71e888316adada5df
- https://git.kernel.org/stable/c/c43991065f36f7628cd124e037b8750c4617a7a7
- https://git.kernel.org/stable/c/e7dc436aea80308a9268e6d2d85f910ff107de9b
Modified: 2025-11-07
CVE-2022-49775
In the Linux kernel, the following vulnerability has been resolved:
tcp: cdg: allow tcp_cdg_release() to be called multiple times
Apparently, mptcp is able to call tcp_disconnect() on an already
disconnected flow. This is generally fine, unless current congestion
control is CDG, because it might trigger a double-free [1]
Instead of fixing MPTCP, and future bugs, we can make tcp_disconnect()
more resilient.
[1]
BUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline]
BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567
CPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: events mptcp_worker
Call Trace:
- https://git.kernel.org/stable/c/0b19171439016a8e4c97eafe543670ac86e2b8fe
- https://git.kernel.org/stable/c/1b639be27cbf428a5ca01dcf8b5d654194c956f8
- https://git.kernel.org/stable/c/35309be06b6feded2ab2cafbc2bca8534c2fa41e
- https://git.kernel.org/stable/c/4026033907cc6186d86b48daa4a252c860db2536
- https://git.kernel.org/stable/c/72e560cb8c6f80fc2b4afc5d3634a32465e13a51
- https://git.kernel.org/stable/c/78be2ee0112409ae4e9ee9e326151e0559b3d239
- https://git.kernel.org/stable/c/9e481d87349d2282f400ee1d010a169c99f766b8
- https://git.kernel.org/stable/c/b49026d9c86f35a4c5bfb8d7345c9c4379828c6b
Modified: 2025-11-07
CVE-2022-49776
In the Linux kernel, the following vulnerability has been resolved:
macvlan: enforce a consistent minimal mtu
macvlan should enforce a minimal mtu of 68, even at link creation.
This patch avoids the current behavior (which could lead to crashes
in ipv6 stack if the link is brought up)
$ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail !
$ ip link sh dev macvlan1
5: macvlan1@eno1:
- https://git.kernel.org/stable/c/2b055c719d8f94c15ec9b7659978133030c6a353
- https://git.kernel.org/stable/c/650137a7c0b2892df2e5b0bc112d7b09a78c93c8
- https://git.kernel.org/stable/c/a62aa84fe19eb24d083d600a074c009a0a66d4f3
- https://git.kernel.org/stable/c/b64085b00044bdf3cd1c9825e9ef5b2e0feae91a
- https://git.kernel.org/stable/c/d2fee7d121d189c6dc905b727d60e7043a6655bb
- https://git.kernel.org/stable/c/e41cbf98df22d08402e65174d147cbb187fe1a33
- https://git.kernel.org/stable/c/e929ec98c0c3b10d9c07f3776df0c1a02d7a763e
Modified: 2025-11-07
CVE-2022-49777
In the Linux kernel, the following vulnerability has been resolved: Input: i8042 - fix leaking of platform device on module removal Avoid resetting the module-wide i8042_platform_device pointer in i8042_probe() or i8042_remove(), so that the device can be properly destroyed by i8042_exit() on module unload.
- https://git.kernel.org/stable/c/3f25add5ecf88de0f8ff2b27b6c0731a1f1b38ed
- https://git.kernel.org/stable/c/4f348b60c79671eee33c1389efe89109c93047da
- https://git.kernel.org/stable/c/81cd7e8489278d28794e7b272950c3e00c344e44
- https://git.kernel.org/stable/c/81df118e79b2136b5c016394f67a051dc508b7b6
- https://git.kernel.org/stable/c/a32cd7feb0127bf629a82686b6e2c128139a86e5
- https://git.kernel.org/stable/c/d5f7f6e63fed9c2ed09725d90059a28907e197e3
Modified: 2025-11-07
CVE-2022-49779
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case
In __unregister_kprobe_top(), if the currently unregistered probe has
post_handler but other child probes of the aggrprobe do not have
post_handler, the post_handler of the aggrprobe is cleared. If this is
a ftrace-based probe, there is a problem. In later calls to
disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is
NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in
__disarm_kprobe_ftrace() and may even cause use-after-free:
Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2)
WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0
Modules linked in: testKprobe_007(-)
CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18
[...]
Call Trace:
- https://git.kernel.org/stable/c/55788ebbe8b365b4375bd56b4ba7db79d393a370
- https://git.kernel.org/stable/c/5dd7caf0bdc5d0bae7cf9776b4d739fb09bd5ebb
- https://git.kernel.org/stable/c/7b0007b28dd970176f2e297c06ae63eea2447127
- https://git.kernel.org/stable/c/7d606ae1abcc3eab5408e42444d789dc7def51b8
- https://git.kernel.org/stable/c/c49cc2c059b503e962c2f13a806c105f9b757df4
Modified: 2025-11-07
CVE-2022-49780
In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus() If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need goto error label in this case.
- https://git.kernel.org/stable/c/28f7ff5e7559d226e63c7c5de74eb075a83d8c53
- https://git.kernel.org/stable/c/41a6b8b527a5957fab41c3c05e25ad125268e2e9
- https://git.kernel.org/stable/c/75205f1b47a88c3fac4f30bd7567e89b2887c7fd
- https://git.kernel.org/stable/c/a636772988bafab89278e7bb3420d8e8eacfe912
- https://git.kernel.org/stable/c/bc68e428d4963af0201e92159629ab96948f0893
- https://git.kernel.org/stable/c/dce0589a3faec9e2e543e97bca7e62592ec85585
Modified: 2025-11-07
CVE-2022-49785
In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Add overflow check in sgx_validate_offset_length() sgx_validate_offset_length() function verifies "offset" and "length" arguments provided by userspace, but was missing an overflow check on their addition. Add it.
Modified: 2025-11-07
CVE-2022-49787
In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before amd_probe() returns. There is no problem for the 'smbus_dev == NULL' branch because pci_dev_put() can also handle the NULL input parameter case.
- https://git.kernel.org/stable/c/222cfa0118aa68687ace74aab8fdf77ce8fbd7e6
- https://git.kernel.org/stable/c/27f712cd47d65e14cd52cc32a23d42aeef583d5d
- https://git.kernel.org/stable/c/35bca18092685b488003509fef7055aa2d4f2ebc
- https://git.kernel.org/stable/c/4423866d31a06a810db22062ed13389416a66b22
- https://git.kernel.org/stable/c/5dbd6378dbf96787d6dbcca44156c511ae085ea3
- https://git.kernel.org/stable/c/7570e5b5419ffd34b6dc45a88c51e113a9a187e3
- https://git.kernel.org/stable/c/a99a547658e5d451f01ed307426286716b6f01bf
Modified: 2025-11-07
CVE-2022-49788
In the Linux kernel, the following vulnerability has been resolved: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use memset() to prevent the infoleaks. Also speculatively fix qp_notify_peer_local(), which may suffer from the same problem.
- https://git.kernel.org/stable/c/5a275528025ae4bc7e2232866856dfebf84b2fad
- https://git.kernel.org/stable/c/62634b43d3c4e1bf62fd540196f7081bf0885c0a
- https://git.kernel.org/stable/c/76c50d77b928a33e5290aaa9fdc10e88254ff8c7
- https://git.kernel.org/stable/c/7ccf7229b96fadc3a185d1391f814a604c7ef609
- https://git.kernel.org/stable/c/8e2f33c598370bcf828bab4d667d1d38bcd3c57d
- https://git.kernel.org/stable/c/e5b0d06d9b10f5f43101bd6598b076c347f9295f
- https://git.kernel.org/stable/c/e7061dd1fef2dfb6458cd521aef27aa66f510d31
- https://git.kernel.org/stable/c/f04586c2315cfd03d72ad0395705435e7ed07b1a
Modified: 2025-11-07
CVE-2022-49789
In the Linux kernel, the following vulnerability has been resolved: scsi: zfcp: Fix double free of FSF request when qdio send fails We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice). If we can't successfully remove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcp_fsf_req_send()' fails, but because the request is still in the hash table we end up with a stale memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice. The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncated---
- https://git.kernel.org/stable/c/0954256e970ecf371b03a6c9af2cf91b9c4085ff
- https://git.kernel.org/stable/c/11edbdee4399401f533adda9bffe94567aa08b96
- https://git.kernel.org/stable/c/1bf8ed585501bb2dd0b5f67c824eab45adfbdccd
- https://git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c125a91f
- https://git.kernel.org/stable/c/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab
Modified: 2025-11-05
CVE-2022-49790
In the Linux kernel, the following vulnerability has been resolved: Input: iforce - invert valid length check when fetching device IDs syzbot is reporting uninitialized value at iforce_init_device() [1], for commit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer when fetching device IDs") is checking that valid length is shorter than bytes to read. Since iforce_get_id_packet() stores valid length when returning 0, the caller needs to check that valid length is longer than or equals to bytes to read.
- https://git.kernel.org/stable/c/24cc679abbf31477d0cc6106ec83c2fbae6b3cdf
- https://git.kernel.org/stable/c/5d53797ce7ce8fb1d95a5bebc5efa9418c4217a3
- https://git.kernel.org/stable/c/6365569d62a75ddf53fb0c2936c16587a365984c
- https://git.kernel.org/stable/c/b8ebf250997c5fb253582f42bfe98673801ebebd
- https://git.kernel.org/stable/c/fdd57c20d4408cac3c3c535c120d244e083406c9
Modified: 2025-11-05
CVE-2022-49792
In the Linux kernel, the following vulnerability has been resolved: iio: adc: mp2629: fix potential array out of bound access Add sentinel at end of maps to avoid potential array out of bound access in iio core.
Modified: 2025-11-06
CVE-2022-49793
In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init() dev_set_name() allocates memory for name, it need be freed when device_add() fails, call put_device() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. Fault injection test can trigger this: unreferenced object 0xffff8e8340a7b4c0 (size 32): comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s) hex dump (first 32 bytes): 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............ backtrace: [<0000000074999de8>] __kmem_cache_alloc_node+0x1e9/0x360 [<00000000497fd30b>] __kmalloc_node_track_caller+0x44/0x1a0 [<000000003636c520>] kstrdup+0x2d/0x60 [<0000000032f84da2>] kobject_set_name_vargs+0x1e/0x90 [<0000000092efe493>] dev_set_name+0x4e/0x70
- https://git.kernel.org/stable/c/0dd52e141afde089304de470148d311b05c14564
- https://git.kernel.org/stable/c/2c4e65285bdea23fd36d2ff376006ac64db6f42e
- https://git.kernel.org/stable/c/5a39382aa5411d64b25a71516c2c7480aab13bb7
- https://git.kernel.org/stable/c/656f670613662b6cc77aad14112db2803ad18fa8
- https://git.kernel.org/stable/c/8dddf2699da296c84205582aaead6b43dd7e8c4b
- https://git.kernel.org/stable/c/b47bb521961f027b4dcf8683337a7a1ba9e5ea1f
- https://git.kernel.org/stable/c/efa17e90e1711bdb084e3954fa44afb6647331c0
- https://git.kernel.org/stable/c/f68c96821b61d2c71a35dbb8bf90c347fad624d9
Modified: 2025-11-06
CVE-2022-49794
In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger() If iio_trigger_register() returns error, it should call iio_trigger_free() to give up the reference that hold in iio_trigger_alloc(), so that it can call iio_trig_release() to free memory when the refcount hit to 0.
- https://git.kernel.org/stable/c/1bf8c0aff8fb5c4edf3ba6728e6bedbd610d7f4b
- https://git.kernel.org/stable/c/2b29a7f2d52fb5281b30cf61c947d88bab18a29b
- https://git.kernel.org/stable/c/65f20301607d07ee279b0804d11a05a62a6c1a1c
- https://git.kernel.org/stable/c/7b75515728b628a9a7540f201efdeb8ca7299385
- https://git.kernel.org/stable/c/85d2a8b287a89853c0dcfc5a97b5e9d36376fe37
- https://git.kernel.org/stable/c/a0d98ae5a62a7bbad8fcf9fa22e0a1274197bbc4
- https://git.kernel.org/stable/c/c27a3b6ba23350708cf5ab9962337447b51eb76d
- https://git.kernel.org/stable/c/c3ce73f60599a483dca7becd4112508833a40ef9
Modified: 2025-11-06
CVE-2022-49796
In the Linux kernel, the following vulnerability has been resolved:
tracing: kprobe: Fix potential null-ptr-deref on trace_array in kprobe_event_gen_test_exit()
When test_gen_kprobe_cmd() failed after kprobe_event_gen_cmd_end(), it
will goto delete, which will call kprobe_event_delete() and release the
corresponding resource. However, the trace_array in gen_kretprobe_test
will point to the invalid resource. Set gen_kretprobe_test to NULL
after called kprobe_event_delete() to prevent null-ptr-deref.
BUG: kernel NULL pointer dereference, address: 0000000000000070
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 246 Comm: modprobe Tainted: G W
6.1.0-rc1-00174-g9522dc5c87da-dirty #248
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0
Code: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c
01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 <44> 8b 65
70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f
RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000
RDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
R10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064
R13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000
FS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-06
CVE-2022-49797
In the Linux kernel, the following vulnerability has been resolved:
tracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit()
When trace_get_event_file() failed, gen_kretprobe_test will be assigned
as the error code. If module kprobe_event_gen_test is removed now, the
null pointer dereference will happen in kprobe_event_gen_test_exit().
Check if gen_kprobe_test or gen_kretprobe_test is error code or NULL
before dereference them.
BUG: kernel NULL pointer dereference, address: 0000000000000012
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 3 PID: 2210 Comm: modprobe Not tainted
6.1.0-rc1-00171-g2159299a3b74-dirty #217
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test]
Code: Unable to access opcode bytes at 0xffffffff9ffffff2.
RSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246
RAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000
RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c
RBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800
R13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-07
CVE-2022-49798
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race where eprobes can be called before the event The flag that tells the event to call its triggers after reading the event is set for eprobes after the eprobe is enabled. This leads to a race where the eprobe may be triggered at the beginning of the event where the record information is NULL. The eprobe then dereferences the NULL record causing a NULL kernel pointer bug. Test for a NULL record to keep this from happening.
Modified: 2025-11-07
CVE-2022-49799
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix wild-memory-access in register_synth_event()
In register_synth_event(), if set_synth_event_print_fmt() failed, then
both trace_remove_event_call() and unregister_trace_event() will be
called, which means the trace_event_call will call
__unregister_trace_event() twice. As the result, the second unregister
will causes the wild-memory-access.
register_synth_event
set_synth_event_print_fmt failed
trace_remove_event_call
event_remove
if call->event.funcs then
__unregister_trace_event (first call)
unregister_trace_event
__unregister_trace_event (second call)
Fix the bug by avoiding to call the second __unregister_trace_event() by
checking if the first one is called.
general protection fault, probably for non-canonical address
0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI
KASAN: maybe wild-memory-access in range
[0xdead000000000120-0xdead000000000127]
CPU: 0 PID: 3807 Comm: modprobe Not tainted
6.1.0-rc1-00186-g76f33a7eedb4 #299
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:unregister_trace_event+0x6e/0x280
Code: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48
b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02
00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b
RSP: 0018:ffff88810413f370 EFLAGS: 00010a06
RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000
RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20
RBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481
R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122
R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028
FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-07
CVE-2022-49800
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event() test_gen_synth_cmd() only free buf in fail path, hence buf will leak when there is no failure. Add kfree(buf) to prevent the memleak. The same reason and solution in test_empty_synth_event(). unreferenced object 0xffff8881127de000 (size 2048): comm "modprobe", pid 247, jiffies 4294972316 (age 78.756s) hex dump (first 32 bytes): 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_ backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<0000000039eb1cf5>] 0xffffffffa00083cd [<000000000e8c3bc8>] 0xffffffffa00086ba [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd unreferenced object 0xffff8881127df000 (size 2048): comm "modprobe", pid 247, jiffies 4294972324 (age 78.728s) hex dump (first 32 bytes): 20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73 empty_synth_tes 74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 t pid_t next_pi backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<00000000d4db9a3d>] 0xffffffffa0008071 [<00000000c31354a5>] 0xffffffffa00086ce [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Modified: 2025-11-07
CVE-2022-49801
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory leak in tracing_read_pipe() kmemleak reports this issue: unreferenced object 0xffff888105a18900 (size 128): comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] __kmalloc_node_track_caller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150 [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0 [<0000000065629d9d>] trace_event_printf+0xb6/0xf0 [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0 [<00000000d22db172>] print_trace_line+0x73c/0x1480 [<00000000cdba76ba>] tracing_read_pipe+0x45c/0x9f0 [<0000000015b58459>] vfs_read+0x17b/0x7c0 [<000000004aeee8ed>] ksys_read+0xed/0x1c0 [<0000000063d3d898>] do_syscall_64+0x3b/0x90 [<00000000a06dda7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd iter->fmt alloced in tracing_read_pipe() -> .. ->trace_iter_expand_format(), but not freed, to fix, add free in tracing_release_pipe()
Modified: 2025-11-07
CVE-2022-49802
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix null pointer dereference in ftrace_add_mod()
The @ftrace_mod is allocated by kzalloc(), so both the members {prev,next}
of @ftrace_mode->list are NULL, it's not a valid state to call list_del().
If kstrdup() for @ftrace_mod->{func|module} fails, it goes to @out_free
tag and calls free_ftrace_mod() to destroy @ftrace_mod, then list_del()
will write prev->next and next->prev, where null pointer dereference
happens.
BUG: kernel NULL pointer dereference, address: 0000000000000008
Oops: 0002 [#1] PREEMPT SMP NOPTI
Call Trace:
- https://git.kernel.org/stable/c/19ba6c8af9382c4c05dc6a0a79af3013b9a35cd0
- https://git.kernel.org/stable/c/1bea037a1abb23a6729bef36a2265a4565f5ea77
- https://git.kernel.org/stable/c/665b4c6648bf2b91f69b33817f4321cf4c3cafe9
- https://git.kernel.org/stable/c/6a14828caddad0d989495a72af678adf60992704
- https://git.kernel.org/stable/c/6e50eb4b1807017f6c2d5089064256ce2de8aef1
- https://git.kernel.org/stable/c/b5bfc61f541d3f092b13dedcfe000d86eb8e133c
- https://git.kernel.org/stable/c/f715f31559b82e3f75ce047fa476de63d8107584
Modified: 2025-11-07
CVE-2022-49806
In the Linux kernel, the following vulnerability has been resolved: net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start() sparx_stats_init() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. So as sparx5_start().
Modified: 2025-11-07
CVE-2022-49809
In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix skb leak in x25_lapb_receive_frame() x25_lapb_receive_frame() using skb_copy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak.
- https://git.kernel.org/stable/c/0ef17d966445358a55c5f4ccf2c73cca3e39192b
- https://git.kernel.org/stable/c/2929cceb2fcf0ded7182562e4888afafece82cce
- https://git.kernel.org/stable/c/2d675be16a461310d738d93f9f1a00da62055c5a
- https://git.kernel.org/stable/c/9f00da9c866d506998bf0a3f699ec900730472da
- https://git.kernel.org/stable/c/c8baf1fc248b2e88642f094fea9509a9bf98c5bb
- https://git.kernel.org/stable/c/dfcfbe4f2e4b2c81cff4e79b48502d97fda73118
- https://git.kernel.org/stable/c/e109b41870db995cae25dfaf0cc3922f9028b1a1
- https://git.kernel.org/stable/c/fda0ba7c84b46d10947c687320804b9de149a921
Modified: 2025-11-07
CVE-2022-49811
In the Linux kernel, the following vulnerability has been resolved: drbd: use after free in drbd_create_device() The drbd_destroy_connection() frees the "connection" so use the _safe() iterator to prevent a use after free.
- https://git.kernel.org/stable/c/7d93417d596402ddd46bd76c721f205d09d0d025
- https://git.kernel.org/stable/c/813a8dd9c45fd46f5cbbfbedf0791afa7740ccf5
- https://git.kernel.org/stable/c/9ed51414aef6e59e832e2960f10766dce2d5b1a1
- https://git.kernel.org/stable/c/a7a1598189228b5007369a9622ccdf587be0730f
- https://git.kernel.org/stable/c/bf47ca1b35fc1f55091ffaff5fbe41ea0c6f59a1
- https://git.kernel.org/stable/c/c2a00b149836d60c222930bbea6b2139caf34d4f
- https://git.kernel.org/stable/c/fc1897f16ebcfd22364f2afcc27f53a740f3bc7a
Modified: 2025-11-07
CVE-2022-49812
In the Linux kernel, the following vulnerability has been resolved: bridge: switchdev: Fix memory leaks when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm "ip", pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Modified: 2025-11-07
CVE-2022-49813
In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix error handling in ena_init() The ena_init() won't destroy workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak.
Modified: 2025-11-07
CVE-2022-49814
In the Linux kernel, the following vulnerability has been resolved: kcm: close race conditions on sk_receive_queue sk->sk_receive_queue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rx_lock to protect more than just skb queue. However, kcm_recvmsg() still only grabs the skb queue lock, so race conditions still exist. We can teach kcm_recvmsg() to grab mux->rx_lock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets. So we have to enforce skb queue lock in requeue_rx_msgs() and handle skb peek case carefully in kcm_wait_data(). Fortunately, skb_recv_datagram() already handles it nicely and is widely used by other sockets, we can just switch to skb_recv_datagram() after getting rid of the unnecessary sock lock in kcm_recvmsg() and kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets, so it is safe to get rid of this check too. I ran the original syzbot reproducer for 30 min without seeing any issue.
- https://git.kernel.org/stable/c/22f6b5d47396b4287662668ee3f5c1f766cb4259
- https://git.kernel.org/stable/c/4154b6afa2bd639214ff259d912faad984f7413a
- https://git.kernel.org/stable/c/5121197ecc5db58c07da95eb1ff82b98b121a221
- https://git.kernel.org/stable/c/bf92e54597d842da127c59833b365d6faeeaf020
- https://git.kernel.org/stable/c/ce57d6474ae999a3b2d442314087473a646a65c7
- https://git.kernel.org/stable/c/d9ad4de92e184b19bcae4da10dac0275abf83931
- https://git.kernel.org/stable/c/f7b0e95071bb4be4b811af3f0bfc3e200eedeaa3
Modified: 2025-11-07
CVE-2022-49817
In the Linux kernel, the following vulnerability has been resolved: net: mhi: Fix memory leak in mhi_net_dellink() MHI driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch calls free_netdev() to fix it since netdev_priv is used after unregister.
Modified: 2025-11-10
CVE-2022-49821
In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_dsp_element_register() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, use put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. The 'entry' is going to be freed in mISDN_dsp_dev_release(), so the kfree() is removed. list_del() is called in mISDN_dsp_dev_release(), so it need be initialized.
- https://git.kernel.org/stable/c/083a2c9ef82e184bdf0b9f9a1e5fc38d32afbb47
- https://git.kernel.org/stable/c/0f2c681900a01e3f23789bca26d88268c3d5b51d
- https://git.kernel.org/stable/c/727ed7d28348c026c7ef4d852f3d0e5054d376e8
- https://git.kernel.org/stable/c/7a05e3929668c8cfef495c69752a9e91fac4878f
- https://git.kernel.org/stable/c/98a2ac1ca8fd6eca6867726fe238d06e75eb1acd
- https://git.kernel.org/stable/c/b119bedbefb7dd9ed8bf8cb9f1056504250d610e
- https://git.kernel.org/stable/c/bbd53d05c4c892080ef3b617eff4f57903acecb9
- https://git.kernel.org/stable/c/d4b8394725079670be309f9a35ad88a8cbbaaefd
Modified: 2025-11-10
CVE-2022-49822
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix connections leak when tlink setup failed If the tlink setup failed, lost to put the connections, then the module refcnt leak since the cifsd kthread not exit. Also leak the fscache info, and for next mount with fsc, it will print the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST) Let's check the result of tlink setup, and do some cleanup.
Modified: 2025-11-10
CVE-2022-49823
In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix error handling in ata_tdev_add() In ata_tdev_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 13 PID: 13603 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #36 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x3a0 lr : device_del+0x44/0x3a0 Call trace: device_del+0x48/0x3a0 attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tdev_delete+0x24/0x50 [libata] ata_tlink_delete+0x40/0xa0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tdev_add(). In the error path, device_del() is called to delete the device which was added earlier in this function, and ata_tdev_free() is called to free ata_dev.
Modified: 2025-11-10
CVE-2022-49824
In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix error handling in ata_tlink_add() In ata_tlink_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #12 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Call trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tlink_delete+0x88/0xb0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tlink_add().
Modified: 2025-11-10
CVE-2022-49825
In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix error handling in ata_tport_add() In ata_tport_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Call trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tport_delete+0x34/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tport_add().
Modified: 2025-11-10
CVE-2022-49826
In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix double ata_host_put() in ata_tport_add() In the error path in ata_tport_add(), when calling put_device(), ata_tport_release() is called, it will put the refcount of 'ap->host'. And then ata_host_put() is called again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null. When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Call trace: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Fix this by removing redundant ata_host_put() in the error path.
- https://git.kernel.org/stable/c/30e12e2be27ac6c4be2af4163c70db381364706f
- https://git.kernel.org/stable/c/377ff82c33c0cb74562a353361b64b33c09562cf
- https://git.kernel.org/stable/c/865a6da40ba092c18292ae5f6194756131293745
- https://git.kernel.org/stable/c/8c76310740807ade5ecdab5888f70ecb6d35732e
- https://git.kernel.org/stable/c/ac471468f7c16cda2525909946ca13ddbcd14000
- https://git.kernel.org/stable/c/bec9ded5404cb14e5f5470103d0973a2ff83d6a5
Modified: 2025-11-10
CVE-2022-49827
In the Linux kernel, the following vulnerability has been resolved:
drm: Fix potential null-ptr-deref in drm_vblank_destroy_worker()
drm_vblank_init() call drmm_add_action_or_reset() with
drm_vblank_init_release() as action. If __drmm_add_action() failed, will
directly call drm_vblank_init_release() with the vblank whose worker is
NULL. As the resule, a null-ptr-deref will happen in
kthread_destroy_worker(). Add the NULL check before calling
drm_vblank_destroy_worker().
BUG: null-ptr-deref
KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
CPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty
RIP: 0010:kthread_destroy_worker+0x25/0xb0
Call Trace:
Modified: 2025-11-10
CVE-2022-49828
In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: don't delete error page from pagecache This change is very similar to the change that was made for shmem [1], and it solves the same problem but for HugeTLBFS instead. Currently, when poison is found in a HugeTLB page, the page is removed from the page cache. That means that attempting to map or read that hugepage in the future will result in a new hugepage being allocated instead of notifying the user that the page was poisoned. As [1] states, this is effectively memory corruption. The fix is to leave the page in the page cache. If the user attempts to use a poisoned HugeTLB page with a syscall, the syscall will fail with EIO, the same error code that shmem uses. For attempts to map the page, the thread will get a BUS_MCEERR_AR SIGBUS. [1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Modified: 2025-11-10
CVE-2022-49830
In the Linux kernel, the following vulnerability has been resolved: drm/drv: Fix potential memory leak in drm_dev_init() drm_dev_init() will add drm_dev_init_release() as a callback. When drmm_add_action() failed, the release function won't be added. As the result, the ref cnt added by device_get() in drm_dev_init() won't be put by drm_dev_init_release(), which leads to the memleak. Use drmm_add_action_or_reset() instead of drmm_add_action() to prevent memleak. unreferenced object 0xffff88810bc0c800 (size 2048): comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s) hex dump (first 32 bytes): e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................ 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<............. backtrace: [<000000007251f72d>] __kmalloc+0x4b/0x1c0 [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0 [<000000004452a479>] platform_device_register_full+0x24/0x1c0 [<0000000089f4ea61>] 0xffffffffa0736051 [<00000000235b2441>] do_one_initcall+0x7a/0x380 [<0000000001a4a177>] do_init_module+0x5c/0x230 [<000000002bf8a8e2>] load_module+0x227d/0x2420 [<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140 [<00000000c99fc324>] do_syscall_64+0x3f/0x90 [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Modified: 2025-11-10
CVE-2022-49831
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: initialize device's zone info for seeding When performing seeding on a zoned filesystem it is necessary to initialize each zoned device's btrfs_zoned_device_info structure, otherwise mounting the filesystem will cause a NULL pointer dereference. This was uncovered by fstests' testcase btrfs/163.
Modified: 2025-11-10
CVE-2022-49832
In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map Here is the BUG report by KASAN about null pointer dereference: BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50 Read of size 1 at addr 0000000000000000 by task python3/2640 Call Trace: strcmp __of_find_property of_find_property pinctrl_dt_to_map kasprintf() would return NULL pointer when kmalloc() fail to allocate. So directly return ENOMEM, if kasprintf() return NULL pointer.
- https://git.kernel.org/stable/c/040f726fecd88121f3b95e70369785ad452dddf9
- https://git.kernel.org/stable/c/5834a3a98cd266ad35a229923c0adbd0addc8d68
- https://git.kernel.org/stable/c/777430aa4ddccaa5accec6db90ffc1d47f00d471
- https://git.kernel.org/stable/c/91d5c5060ee24fe8da88cd585bb43b843d2f0dce
- https://git.kernel.org/stable/c/97e5b508e96176f1a73888ed89df396d7041bfcb
- https://git.kernel.org/stable/c/a988dcd3dd9e691c5ccc3324b209688f3b5453e9
- https://git.kernel.org/stable/c/aaf552c5d53abe4659176e099575fe870d2e4768
- https://git.kernel.org/stable/c/b4d9f55cd38435358bc16d580612bc0d798d7b4c
Modified: 2025-11-10
CVE-2022-49834
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free bug of ns_writer on remount If a nilfs2 filesystem is downgraded to read-only due to metadata corruption on disk and is remounted read/write, or if emergency read-only remount is performed, detaching a log writer and synchronizing the filesystem can be done at the same time. In these cases, use-after-free of the log writer (hereinafter nilfs->ns_writer) can happen as shown in the scenario below: Task1 Task2 -------------------------------- ------------------------------ nilfs_construct_segment nilfs_segctor_sync init_wait init_waitqueue_entry add_wait_queue schedule nilfs_remount (R/W remount case) nilfs_attach_log_writer nilfs_detach_log_writer nilfs_segctor_destroy kfree finish_wait _raw_spin_lock_irqsave __raw_spin_lock_irqsave do_raw_spin_lock debug_spin_lock_before <-- use-after-free While Task1 is sleeping, nilfs->ns_writer is freed by Task2. After Task1 waked up, Task1 accesses nilfs->ns_writer which is already freed. This scenario diagram is based on the Shigeru Yoshida's post [1]. This patch fixes the issue by not detaching nilfs->ns_writer on remount so that this UAF race doesn't happen. Along with this change, this patch also inserts a few necessary read-only checks with superblock instance where only the ns_writer pointer was used to check if the filesystem is read-only.
- https://git.kernel.org/stable/c/39a3ed68270b079c6b874d4e4727a512b9b4882c
- https://git.kernel.org/stable/c/4feedde5486c07ea79787839153a71ca71329c7d
- https://git.kernel.org/stable/c/8cccf05fe857a18ee26e20d11a8455a73ffd4efd
- https://git.kernel.org/stable/c/9b162e81045266a2d5b44df9dffdf05c54de9cca
- https://git.kernel.org/stable/c/afbd1188382a75f6cfe22c0b68533f7f9664f182
- https://git.kernel.org/stable/c/b152300d5a1ba4258dacf9916bff20e6a8c7603b
- https://git.kernel.org/stable/c/b2fbf10040216ef5ee270773755fc2f5da65b749
- https://git.kernel.org/stable/c/b4736ab5542112fe0a40f140a0a0b072954f34da
Modified: 2025-11-10
CVE-2022-49835
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix potential memleak in 'add_widget_node' As 'kobject_add' may allocated memory for 'kobject->name' when return error. And in this function, if call 'kobject_add' failed didn't free kobject. So call 'kobject_put' to recycling resources.
- https://git.kernel.org/stable/c/02dea987ec1cac712c78e75d224ceb9bb73519ed
- https://git.kernel.org/stable/c/3a79f9568de08657fcdbc41d6fc4c0ca145a7a2b
- https://git.kernel.org/stable/c/455d99bd6baf19688048b6d42d9fa74eae27f93b
- https://git.kernel.org/stable/c/7140d7aaf93da6a665b454f91bb4dc6b1de218bd
- https://git.kernel.org/stable/c/90b7d055e2b5f39429f9a9e3815b48a48530ef28
- https://git.kernel.org/stable/c/9a5523f72bd2b0d66eef3d58810c6eb7b5ffc143
- https://git.kernel.org/stable/c/b688a3ec235222d9a84e43a48a6f31acb95baf2d
- https://git.kernel.org/stable/c/bb0ac8d5e541224f599bc8e8f31a313faa4bf7b7
Modified: 2025-11-10
CVE-2022-49836
In the Linux kernel, the following vulnerability has been resolved: siox: fix possible memory leak in siox_device_add() If device_register() returns error in siox_device_add(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(), and sdevice is freed in siox_device_release(), set it to null in error path.
- https://git.kernel.org/stable/c/0a5da069603ecc3d7aa09167450235462adaa295
- https://git.kernel.org/stable/c/5d03c2911c529ea4d6ebfec53425f1091e8d402b
- https://git.kernel.org/stable/c/6e63153db50059fb78b8a8447b132664887d24e3
- https://git.kernel.org/stable/c/a4b5423f88a17a36550ae8c16c46779b1ee42f4b
- https://git.kernel.org/stable/c/d9c31e728843259209fb530c59995e4fe262699f
- https://git.kernel.org/stable/c/f9fe7ba4ea5b24ffdf8e125f660aca3ba4a147fb
Modified: 2025-10-01
CVE-2022-49837
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix memory leaks in __check_func_call kmemleak reports this issue: unreferenced object 0xffff88817139d000 (size 2048): comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b/0x90 [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The root case here is: In function prepare_func_exit(), the callee is not released in the abnormal scenario after "state->curframe--;". To fix, move "state->curframe--;" to the very bottom of the function, right when we free callee and reset frame[] pointer to NULL, as Andrii suggested. In addition, function __check_func_call() has a similar problem. In the abnormal scenario before "state->curframe++;", the callee also should be released by free_func_state().
Modified: 2025-11-10
CVE-2022-49838
In the Linux kernel, the following vulnerability has been resolved: sctp: clear out_curr if all frag chunks of current msg are pruned A crash was reported by Zhen Chen: list_del corruption, ffffa035ddf01c18->next is NULL WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Call Trace: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70 and in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream out_curr outq while this outq was empty. Normally stream->out_curr must be set to NULL once all frag chunks of current msg are dequeued, as we can see in sctp_sched_dequeue_done(). However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue, sctp_sched_dequeue_done() is not called to do this. This patch is to fix it by simply setting out_curr to NULL when the last frag chunk of current msg is dequeued from out_curr stream in sctp_prsctp_prune_unsent().
Modified: 2025-10-01
CVE-2022-49839
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_transport_sas: Fix error handling in sas_phy_add() If transport_add_device() fails in sas_phy_add(), the kernel will crash trying to delete the device in transport_remove_device() called from sas_remove_host(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_phy_delete+0x30/0x60 [scsi_transport_sas] do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x40/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] hisi_sas_remove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by checking and handling return value of transport_add_device() in sas_phy_add().
Modified: 2025-10-01
CVE-2022-49840
In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb() We got a syzkaller problem because of aarch64 alignment fault if KFENCE enabled. When the size from user bpf program is an odd number, like 399, 407, etc, it will cause the struct skb_shared_info's unaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381 To fix the problem, we adjust @size so that (@size + @hearoom) is a multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info is aligned to a cache line.
- https://git.kernel.org/stable/c/047824a730699c6c66df43306b80f700c9dfc2fd
- https://git.kernel.org/stable/c/1b597f2d6a55e9f549989913860ad5170da04964
- https://git.kernel.org/stable/c/730fb1ef974a13915bc7651364d8b3318891cd70
- https://git.kernel.org/stable/c/7a704dbfd3735304e261f2787c52fbc7c3884736
- https://git.kernel.org/stable/c/d3fd203f36d46aa29600a72d57a1b61af80e4a25
- https://git.kernel.org/stable/c/e60f37a1d379c821c17b08f366412dce9ef3d99f
- https://git.kernel.org/stable/c/eaa8edd86514afac9deb9bf9a5053e74f37edf40
Modified: 2025-11-10
CVE-2022-49841
In the Linux kernel, the following vulnerability has been resolved: serial: imx: Add missing .thaw_noirq hook The following warning is seen with non-console UART instance when system hibernates. [ 37.371969] ------------[ cut here ]------------ [ 37.376599] uart3_root_clk already disabled [ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 ... [ 37.506986] Call trace: [ 37.509432] clk_core_disable+0xa4/0xb0 [ 37.513270] clk_disable+0x34/0x50 [ 37.516672] imx_uart_thaw+0x38/0x5c [ 37.520250] platform_pm_thaw+0x30/0x6c [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4 [ 37.528972] device_resume+0x7c/0x160 [ 37.532633] dpm_resume+0xe8/0x230 [ 37.536036] hibernation_snapshot+0x288/0x430 [ 37.540397] hibernate+0x10c/0x2e0 [ 37.543798] state_store+0xc4/0xd0 [ 37.547203] kobj_attr_store+0x1c/0x30 [ 37.550953] sysfs_kf_write+0x48/0x60 [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac [ 37.559063] new_sync_write+0xe8/0x184 [ 37.562812] vfs_write+0x230/0x290 [ 37.566214] ksys_write+0x68/0xf4 [ 37.569529] __arm64_sys_write+0x20/0x2c [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0 [ 37.578156] do_el0_svc+0x11c/0x150 [ 37.581648] el0_svc+0x30/0x140 [ 37.584792] el0t_64_sync_handler+0xe8/0xf0 [ 37.588976] el0t_64_sync+0x1a0/0x1a4 [ 37.592639] ---[ end trace 56e22eec54676d75 ]--- On hibernating, pm core calls into related hooks in sequence like: .freeze .freeze_noirq .thaw_noirq .thaw With .thaw_noirq hook being absent, the clock will be disabled in a unbalanced call which results the warning above. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_thaw clk_disable_unprepare() Adding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have the call sequence corrected as below and thus fix the warning. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_resume_noirq() clk_enable() imx_uart_thaw clk_disable_unprepare()
- https://git.kernel.org/stable/c/0a3160f4ffc70ee4bfa1521f698dace06e6091fd
- https://git.kernel.org/stable/c/4561d8008a467cb05ac632a215391d6b787f40aa
- https://git.kernel.org/stable/c/476b09e07bd519ec7ba5941a6a6f9a02256dbb21
- https://git.kernel.org/stable/c/ae22294e213a402a70fa1731538367d1b758ffe7
- https://git.kernel.org/stable/c/e3f9d87d6f0732827c443bd1474df21c2fad704b
- https://git.kernel.org/stable/c/e401312ca6e180ee1bd65f6a766e99dd40aa95e7
Modified: 2025-10-01
CVE-2022-49842
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Fix use-after-free in snd_soc_exit()
KASAN reports a use-after-free:
BUG: KASAN: use-after-free in device_del+0xb5b/0xc60
Read of size 8 at addr ffff888008655050 by task rmmod/387
CPU: 2 PID: 387 Comm: rmmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
- https://git.kernel.org/stable/c/2ec3f558db343b045a7c7419cdbaec266b8ac1a7
- https://git.kernel.org/stable/c/34eee4189bcebbd5f6a2ff25ef0cb893ad33d51e
- https://git.kernel.org/stable/c/41fad4f712e081acdfde8b59847f9f66eaf407a0
- https://git.kernel.org/stable/c/6ec27c53886c8963729885bcf2dd996eba2767a7
- https://git.kernel.org/stable/c/8d21554ec7680e9585fb852d933203c3db60dad1
- https://git.kernel.org/stable/c/90bbdf30a51e42378cb23a312005a022794b8e1e
- https://git.kernel.org/stable/c/a3365e62239dc064019a244bde5686ac18527c22
- https://git.kernel.org/stable/c/c5674bd073c0fd9f620ca550c5ff08d0d429bdd9
Modified: 2025-10-01
CVE-2022-49845
In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_send_one(): fix missing CAN header initialization The read access to struct canxl_frame::len inside of a j1939 created skbuff revealed a missing initialization of reserved and later filled elements in struct can_frame. This patch initializes the 8 byte CAN header with zero.
- https://git.kernel.org/stable/c/2719f82ad5d8199cf5f346ea8bb3998ad5323b72
- https://git.kernel.org/stable/c/3eb3d283e8579a22b81dd2ac3987b77465b2a22f
- https://git.kernel.org/stable/c/69e86c6268d59ceddd0abe9ae8f1f5296f316c3c
- https://git.kernel.org/stable/c/d0513b095e1ef1469718564dec3fb3348556d0a8
- https://git.kernel.org/stable/c/f8e0edeaa0f2b860bdbbf0aafb4492533043d650
Modified: 2025-10-01
CVE-2022-49846
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix a slab-out-of-bounds write bug in udf_find_entry()
Syzbot reported a slab-out-of-bounds Write bug:
loop0: detected capacity change from 0 to 2048
==================================================================
BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0
fs/udf/namei.c:253
Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610
CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted
6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/11/2022
Call Trace:
- https://git.kernel.org/stable/c/03f9582a6a2ebd25a440896475c968428c4b63e7
- https://git.kernel.org/stable/c/583fdd98d94acba1e7225e5cc29063aef0741030
- https://git.kernel.org/stable/c/7a6051d734f1ed0031e2216f9a538621235c11a4
- https://git.kernel.org/stable/c/ac79001b8e603226fab17240a79cb9ef679d3cd9
- https://git.kernel.org/stable/c/c736ed8541605e3a25075bb1cbf8f38cb3083238
- https://git.kernel.org/stable/c/c8af247de385ce49afabc3bf1cf4fd455c94bfe8
- https://git.kernel.org/stable/c/d8971f410739a864c537e0ac29344a7b6c450232
- https://git.kernel.org/stable/c/f1517721c408631f09d54c743aa70cb07fd3eebd
Modified: 2025-11-10
CVE-2022-49849
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix match incorrectly in dev_args_match_device syzkaller found a failed assertion: assertion failed: (args->devid != (u64)-1) || args->missing, in fs/btrfs/volumes.c:6921 This can be triggered when we set devid to (u64)-1 by ioctl. In this case, the match of devid will be skipped and the match of device may succeed incorrectly. Patch 562d7b1512f7 introduced this function which is used to match device. This function contains two matching scenarios, we can distinguish them by checking the value of args->missing rather than check whether args->devid and args->uuid is default value.
Modified: 2025-10-01
CVE-2022-49850
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix deadlock in nilfs_count_free_blocks() A semaphore deadlock can occur if nilfs_get_block() detects metadata corruption while locating data blocks and a superblock writeback occurs at the same time: task 1 task 2 ------ ------ * A file operation * nilfs_truncate() nilfs_get_block() down_read(rwsem A) <-- nilfs_bmap_lookup_contig() ... generic_shutdown_super() nilfs_put_super() * Prepare to write superblock * down_write(rwsem B) <-- nilfs_cleanup_super() * Detect b-tree corruption * nilfs_set_log_cursor() nilfs_bmap_convert_error() nilfs_count_free_blocks() __nilfs_error() down_read(rwsem A) <-- nilfs_set_error() down_write(rwsem B) <-- *** DEADLOCK *** Here, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem) and then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata corruption, __nilfs_error() is called from nilfs_bmap_convert_error() inside the lock section. Since __nilfs_error() calls nilfs_set_error() unless the filesystem is read-only and nilfs_set_error() attempts to writelock rwsem B (= nilfs->ns_sem) to write back superblock exclusively, hierarchical lock acquisition occurs in the order rwsem A -> rwsem B. Now, if another task starts updating the superblock, it may writelock rwsem B during the lock sequence above, and can deadlock trying to readlock rwsem A in nilfs_count_free_blocks(). However, there is actually no need to take rwsem A in nilfs_count_free_blocks() because it, within the lock section, only reads a single integer data on a shared struct with nilfs_sufile_get_ncleansegs(). This has been the case after commit aa474a220180 ("nilfs2: add local variable to cache the number of clean segments"), that is, even before this bug was introduced. So, this resolves the deadlock problem by just not taking the semaphore in nilfs_count_free_blocks().
- https://git.kernel.org/stable/c/1d4ff73062096c21b47954d2996b4df259777bda
- https://git.kernel.org/stable/c/36ff974b0310771417c0be64b64aa221bd70d63d
- https://git.kernel.org/stable/c/3c89ca6d3dfa6c09c515807a7a97a521f5d5147e
- https://git.kernel.org/stable/c/8ac932a4921a96ca52f61935dbba64ea87bbd5dc
- https://git.kernel.org/stable/c/8b4506cff6630bb474bb46a2a75c31e533a756ba
- https://git.kernel.org/stable/c/abc082aac0d9b6b926038fc3adb7008306581be2
- https://git.kernel.org/stable/c/cb029b54953420f7a2d65100f1c5107f14411bdc
- https://git.kernel.org/stable/c/f0cc93080d4c09510b74ecba87fd778cca390bb1
Modified: 2025-11-10
CVE-2022-49851
In the Linux kernel, the following vulnerability has been resolved:
riscv: fix reserved memory setup
Currently, RISC-V sets up reserved memory using the "early" copy of the
device tree. As a result, when trying to get a reserved memory region
using of_reserved_mem_lookup(), the pointer to reserved memory regions
is using the early, pre-virtual-memory address which causes a kernel
panic when trying to use the buffer's name:
Unable to handle kernel paging request at virtual address 00000000401c31ac
Oops [#1]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1
Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
epc : string+0x4a/0xea
ra : vsnprintf+0x1e4/0x336
epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0
gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000
t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20
s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000
a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff
a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff
s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008
s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00
s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002
s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617
t5 : ffffffff812f3618 t6 : ffffffff81203d08
status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d
[
Modified: 2026-01-23
CVE-2022-49852
In the Linux kernel, the following vulnerability has been resolved: riscv: process: fix kernel info leakage thread_struct's s[12] may contain random kernel memory content, which may be finally leaked to userspace. This is a security hole. Fix it by clearing the s[12] array in thread_struct when fork. As for kthread case, it's better to clear the s[12] array as well.
- https://git.kernel.org/stable/c/358a68f98304b40b201ba5afe94c20355aa3dc68
- https://git.kernel.org/stable/c/6510c78490c490a6636e48b61eeaa6fb65981f4b
- https://git.kernel.org/stable/c/c4601d30f7d989b4f354df899ab85b5f7a750d30
- https://git.kernel.org/stable/c/c5c0b3167537793a7cf936fb240366eefd2fc7fb
- https://git.kernel.org/stable/c/cc36c7fa5d9384602529ba3eea8c5daee7be4dbc
- https://git.kernel.org/stable/c/e56d18a976dda653194218df6d40d8122c775712
Modified: 2025-10-01
CVE-2022-49853
In the Linux kernel, the following vulnerability has been resolved:
net: macvlan: fix memory leaks of macvlan_common_newlink
kmemleak reports memory leaks in macvlan_common_newlink, as follows:
ip link add link eth0 name .. type macvlan mode source macaddr add
- https://git.kernel.org/stable/c/21d3a8b6a1e39e7529ce9de07316ee13a63f305b
- https://git.kernel.org/stable/c/23569b5652ee8e8e55a12f7835f59af6f3cefc30
- https://git.kernel.org/stable/c/685e73e3f7a9fb75cbf049a9d0b7c45cc6b57b2e
- https://git.kernel.org/stable/c/956e0216a19994443c90ba2ea6b0b284c9c4f9cb
- https://git.kernel.org/stable/c/9ea003c4671b2fc455320ecf6d4a43b0a3c1878a
- https://git.kernel.org/stable/c/9f288e338be206713d79b29144c27fca4503c39b
- https://git.kernel.org/stable/c/a81b44d1df1f07f00c0dcc0a0b3d2fa24a46289e
- https://git.kernel.org/stable/c/a8d67367ab33604326cc37ab44fd1801bf5691ba
Modified: 2025-10-01
CVE-2022-49854
In the Linux kernel, the following vulnerability has been resolved: mctp: Fix an error handling path in mctp_init() If mctp_neigh_init() return error, the routes resources should be released in the error handling path. Otherwise some resources leak.
Modified: 2025-10-01
CVE-2022-49855
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg ipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to obtain the wwan power state configuration from BIOS but is not freeing the acpi_object. The acpi_evaluate_dsm() returned acpi_object to be freed. Free the acpi_object after use.
Modified: 2025-10-01
CVE-2022-49857
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init() When prestera_sdma_switch_init() failed, the memory pointed to by sw->rxtx isn't released. Fix it. Only be compiled, not be tested.
Modified: 2025-11-10
CVE-2022-49859
In the Linux kernel, the following vulnerability has been resolved:
net: lapbether: fix issue of invalid opcode in lapbeth_open()
If lapb_register() failed when lapb device goes to up for the first time,
the NAPI is not disabled. As a result, the invalid opcode issue is
reported when the lapb device goes to up for the second time.
The stack info is as follows:
[ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442!
[ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0
[ 1958.332310][T11356] Call Trace:
[ 1958.332817][T11356]
Modified: 2025-10-01
CVE-2022-49860
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-glue: fix memory leak when register device fail If device_register() fails, it should call put_device() to give up reference, the name allocated in dev_set_name() can be freed in callback function kobject_cleanup().
Modified: 2025-10-01
CVE-2022-49861
In the Linux kernel, the following vulnerability has been resolved: dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() A clk_prepare_enable() call in the probe is not balanced by a corresponding clk_disable_unprepare() in the remove function. Add the missing call.
- https://git.kernel.org/stable/c/04f2cc56d80a1ac058045a7835c5bfd910f17863
- https://git.kernel.org/stable/c/081195d17a0c4c636da2b869bd5809d42e8cbb13
- https://git.kernel.org/stable/c/0b7ee3d50f32d277bf024b4ddb4de54da43a3025
- https://git.kernel.org/stable/c/1d84887327659c58a6637060ac8c50c3a952a163
- https://git.kernel.org/stable/c/20479886b40c0ed4864a5fc8490a1f6b70cccf1b
- https://git.kernel.org/stable/c/4b6641c3a2ba95ddcfecec263b4a5e572a4b0641
- https://git.kernel.org/stable/c/992e966caf57e00855edbd79f19d911809732a69
- https://git.kernel.org/stable/c/a1cb72e20a64a3c83f9b4ee993fbf97e4c1d7714
Modified: 2025-10-01
CVE-2022-49862
In the Linux kernel, the following vulnerability has been resolved: tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value in tipc_nl_compat_name_table_dump") where it should have type casted sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative value. syzbot reported a call trace because of it: BUG: KMSAN: uninit-value in ... tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934 __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238 tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321 tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline]
- https://git.kernel.org/stable/c/082707d3df191bf5bb8801d43e4ce3dea39ca173
- https://git.kernel.org/stable/c/1c075b192fe41030457cd4a5f7dea730412bca40
- https://git.kernel.org/stable/c/301caa06091af4d5cf056ac8249cbda4e6029c6a
- https://git.kernel.org/stable/c/36769b9477491a7af6635863bd950309c1e1b96c
- https://git.kernel.org/stable/c/55a253a6753a603e80b95932ca971ba514aa6ce7
- https://git.kernel.org/stable/c/6cee2c60bd168279852ac7dbe54c2b70d1028644
- https://git.kernel.org/stable/c/a0ead1d648df9c456baec832b494513ef405949a
- https://git.kernel.org/stable/c/f31dd158580940938f77514b87337a777520185a
Modified: 2025-10-01
CVE-2022-49863
In the Linux kernel, the following vulnerability has been resolved:
can: af_can: fix NULL pointer dereference in can_rx_register()
It causes NULL pointer dereference when testing as following:
(a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket.
(b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan
link device, and bind vxcan device to bond device (can also use
ifenslave command to bind vxcan device to bond device).
(c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket.
(d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket.
The bond device invokes the can-raw protocol registration interface to
receive CAN packets. However, ml_priv is not allocated to the dev,
dev_rcv_lists is assigned to NULL in can_rx_register(). In this case,
it will occur the NULL pointer dereference issue.
The following is the stack information:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
RIP: 0010:can_rx_register+0x12d/0x1e0
Call Trace:
- https://git.kernel.org/stable/c/261178a1c2623077d62e374a75c195e6c99a6f05
- https://git.kernel.org/stable/c/8aa59e355949442c408408c2d836e561794c40a1
- https://git.kernel.org/stable/c/a8055677b054bc2bb78beb1080fdc2dc5158c2fe
- https://git.kernel.org/stable/c/afab4655750fcb3fca359bc7d7214e3d634cdf9c
- https://git.kernel.org/stable/c/d68fa77ee3d03bad6fe84e89759ddf7005f9e9c6
Modified: 2025-10-01
CVE-2022-49864
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram() ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but dereferenced.
Modified: 2026-01-23
CVE-2022-49865
In the Linux kernel, the following vulnerability has been resolved: ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network When copying a `struct ifaddrlblmsg` to the network, __ifal_reserved remained uninitialized, resulting in a 1-byte infoleak: BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841 __netdev_start_xmit ./include/linux/netdevice.h:4841 netdev_start_xmit ./include/linux/netdevice.h:4857 xmit_one net/core/dev.c:3590 dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606 __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256 dev_queue_xmit ./include/linux/netdevice.h:3009 __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1263 netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272 netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360 nlmsg_unicast ./include/net/netlink.h:1061 rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758 ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 ... Uninit was created at: slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742 slab_alloc_node mm/slub.c:3398 __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437 __do_kmalloc_node mm/slab_common.c:954 __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975 kmalloc_reserve net/core/skbuff.c:437 __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509 alloc_skb ./include/linux/skbuff.h:1267 nlmsg_new ./include/net/netlink.h:964 ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540 rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345 netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921 ... This patch ensures that the reserved field is always initialized.
- https://git.kernel.org/stable/c/0f85b7ae7c4b5d7b4bbf7ac653a733c181a8a2bf
- https://git.kernel.org/stable/c/2acb2779b147decd300c117683d5a32ce61c75d6
- https://git.kernel.org/stable/c/49e92ba5ecd7d72ba369dde2ccff738edd028a47
- https://git.kernel.org/stable/c/568a47ff756f913e8b374c2af9d22cd2c772c744
- https://git.kernel.org/stable/c/58cd7fdc8c1e6c7873acc08f190069fed88d1c12
- https://git.kernel.org/stable/c/6d26d0587abccb9835382a0b53faa7b9b1cd83e3
- https://git.kernel.org/stable/c/a033b86c7f7621fde31f0364af8986f43b44914f
- https://git.kernel.org/stable/c/c23fb2c82267638f9d206cb96bb93e1f93ad7828
Modified: 2025-10-01
CVE-2022-49866
In the Linux kernel, the following vulnerability has been resolved: net: wwan: mhi: fix memory leak in mhi_mbim_dellink MHI driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch sets needs_free_netdev to true when registers network device, which makes netdev subsystem call free_netdev() automatically after unregister_netdevice().
Modified: 2025-10-01
CVE-2022-49867
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix memory leak in ipc_wwan_dellink IOSM driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch sets needs_free_netdev to true when registers network device, which makes netdev subsystem call free_netdev() automatically after unregister_netdevice().
Modified: 2025-11-10
CVE-2022-49868
In the Linux kernel, the following vulnerability has been resolved: phy: ralink: mt7621-pci: add sentinel to quirks table With mt7621 soc_dev_attr fixed to register the soc as a device, kernel will experience an oops in soc_device_match_attr This quirk test was introduced in the staging driver in commit 9445ccb3714c ("staging: mt7621-pci-phy: add quirks for 'E2' revision using 'soc_device_attribute'"). The staging driver was removed, and later re-added in commit d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY") for kernel 5.11
Modified: 2025-10-01
CVE-2022-49869
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix possible crash in bnxt_hwrm_set_coal() During the error recovery sequence, the rtnl_lock is not held for the entire duration and some datastructures may be freed during the sequence. Check for the BNXT_STATE_OPEN flag instead of netif_running() to ensure that the device is fully operational before proceeding to reconfigure the coalescing settings. This will fix a possible crash like this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G IOE --------- - - 4.18.0-348.el8.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019 RIP: 0010:bnxt_hwrm_set_coal+0x1fb/0x2a0 [bnxt_en] Code: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 <48> 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6 RSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5 RDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28 RBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c R13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0 FS: 00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ethnl_set_coalesce+0x3ce/0x4c0 genl_family_rcv_msg_doit.isra.15+0x10f/0x150 genl_family_rcv_msg+0xb3/0x160 ? coalesce_fill_reply+0x480/0x480 genl_rcv_msg+0x47/0x90 ? genl_family_rcv_msg+0x160/0x160 netlink_rcv_skb+0x4c/0x120 genl_rcv+0x24/0x40 netlink_unicast+0x196/0x230 netlink_sendmsg+0x204/0x3d0 sock_sendmsg+0x4c/0x50 __sys_sendto+0xee/0x160 ? syscall_trace_enter+0x1d3/0x2c0 ? __audit_syscall_exit+0x249/0x2a0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7f38524163bb
- https://git.kernel.org/stable/c/38147073c96dce8c7e142ce0e5f305a420a729ba
- https://git.kernel.org/stable/c/6d81ea3765dfa6c8a20822613c81edad1c4a16a0
- https://git.kernel.org/stable/c/7781e32984cde65549bedc3201537e253297c98d
- https://git.kernel.org/stable/c/a5a05fbef4a0dfe45fe03b2f1d02ba23aebf5384
- https://git.kernel.org/stable/c/ac257c43fa615d22180916074feed803b8bb8cb0
Modified: 2025-11-10
CVE-2022-49870
In the Linux kernel, the following vulnerability has been resolved:
capabilities: fix undefined behavior in bit shift for CAP_TO_MASK
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/151dc8087b5609e53b069c068e3f3ee100efa586
- https://git.kernel.org/stable/c/27bdb134c043ff32c459d98f16550d0ffa0b3c34
- https://git.kernel.org/stable/c/46653972e3ea64f79e7f8ae3aa41a4d3fdb70a13
- https://git.kernel.org/stable/c/5661f111a1616ac105ec8cec81bff99b60f847ac
- https://git.kernel.org/stable/c/5b79fa628e2ab789e629a83cd211ef9b4c1a593e
- https://git.kernel.org/stable/c/65b0bc7a0690861812ade523d19f82688ab819dc
- https://git.kernel.org/stable/c/dbaab08c8677d598244d21afb7818e44e1c5d826
- https://git.kernel.org/stable/c/fcbd2b336834bd24e1d9454ad5737856470c10d7
Modified: 2025-10-01
CVE-2022-49871
In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix memory leaks of napi_get_frags kmemleak reports after running test_progs: unreferenced object 0xffff8881b1672dc0 (size 232): comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150 [<0000000041c7fc09>] __napi_build_skb+0x15/0x50 [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540 [<000000003ecfa30e>] napi_get_frags+0x59/0x140 [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun] [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320 [<000000008f338ea2>] do_iter_write+0x135/0x630 [<000000008a3377a4>] vfs_writev+0x12e/0x440 [<00000000a6b5639a>] do_writev+0x104/0x280 [<00000000ccf065d8>] do_syscall_64+0x3b/0x90 [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: tun_get_user() napi_gro_frags() napi_frags_finish() case GRO_NORMAL: gro_normal_one() list_add_tail(&skb->list, &napi->rx_list); <-- While napi->rx_count < READ_ONCE(gro_normal_batch), <-- gro_normal_list() is not called, napi->rx_list is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tun_napi_del() ... tun_napi_del() netif_napi_del() __netif_napi_del() <-- &napi->rx_list is not empty, which caused memory leaks To fix, add napi_complete() after napi_gro_frags().
- https://git.kernel.org/stable/c/1118b2049d77ca0b505775fc1a8d1909cf19a7ec
- https://git.kernel.org/stable/c/223ef6a94e52331a6a7ef31e59921e0e82d2d40a
- https://git.kernel.org/stable/c/3401f964028ac941425b9b2c8ff8a022539ef44a
- https://git.kernel.org/stable/c/8b12a020b20a78f62bedc50f26db3bf4fadf8cb9
- https://git.kernel.org/stable/c/a4f73f6adc53fd7a3f9771cbc89a03ef39b0b755
- https://git.kernel.org/stable/c/d7569302a7a52a9305d2fb054df908ff985553bb
Modified: 2025-11-10
CVE-2022-49872
In the Linux kernel, the following vulnerability has been resolved: net: gso: fix panic on frag_list with mixed head alloc types Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list"), it is allowed to change gso_size of a GRO packet. However, that commit assumes that "checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too". It turns out this assumption does not hold. We've seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced. There are three different locations where this can be fixed: (1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem. (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list. (3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down. This patch implements (3). To limit the performance impact in skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set that have gso_size changed. Normal paths thus will not hit it. We could check only the last skb but since we need to walk the whole list anyway, let's stay on the safe side.
- https://git.kernel.org/stable/c/0a9f56e525ea871d3950b90076912f5c7494f00f
- https://git.kernel.org/stable/c/50868de7dc4e7f0fcadd6029f32bf4387c102ee6
- https://git.kernel.org/stable/c/5876b7f249a1ecbbcc8e35072c3828d6526d1c3a
- https://git.kernel.org/stable/c/598d9e30927b15731e83797fbd700ecf399f42dd
- https://git.kernel.org/stable/c/65ad047fd83502447269fda8fd26c99077a9af47
- https://git.kernel.org/stable/c/9e4b7a99a03aefd37ba7bb1f022c8efab5019165
- https://git.kernel.org/stable/c/ad25a115f50800c6847e0d841c5c7992a9f7c1b3
- https://git.kernel.org/stable/c/bd5362e58721e4d0d1a37796593bd6e51536ce7a
Modified: 2025-10-01
CVE-2022-49873
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix wrong reg type conversion in release_reference() Some helper functions will allocate memory. To avoid memory leaks, the verifier requires the eBPF program to release these memories by calling the corresponding helper functions. When a resource is released, all pointer registers corresponding to the resource should be invalidated. The verifier use release_references() to do this job, by apply __mark_reg_unknown() to each relevant register. It will give these registers the type of SCALAR_VALUE. A register that will contain a pointer value at runtime, but of type SCALAR_VALUE, which may allow the unprivileged user to get a kernel pointer by storing this register into a map. Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this problem.
Modified: 2025-10-01
CVE-2022-49874
In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: fix possible memory leak in mousevsc_probe() If hid_add_device() returns error, it should call hid_destroy_device() to free hid_dev which is allocated in hid_allocate_device().
- https://git.kernel.org/stable/c/249b743801c00542e9324f87b380032e957a43e8
- https://git.kernel.org/stable/c/5ad95d71344b7ffec360d62591633b3c465dc049
- https://git.kernel.org/stable/c/5f3aba6566b866f5b0a4916f0b2e8a6ae66a6451
- https://git.kernel.org/stable/c/8597b59e3d22b27849bd3e4f92a3d466774bfb04
- https://git.kernel.org/stable/c/a6d2fb1874c52ace1f5cf1966ee558829c5c19b6
- https://git.kernel.org/stable/c/b5bcb94b0954a026bbd671741fdb00e7141f9c91
- https://git.kernel.org/stable/c/e29289d0d8193fca6d2c1f0a1de75cfc80edec00
- https://git.kernel.org/stable/c/ed75d1a1c31a0cae8ecc8bcea710b25c0be68da0
Modified: 2025-10-01
CVE-2022-49875
In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE When using bpftool to pin {PROG, MAP, LINK} without FILE, segmentation fault will occur. The reson is that the lack of FILE will cause strlen to trigger NULL pointer dereference. The corresponding stacktrace is shown below: do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- NULL pointer dereference Fix it by adding validation to the common process.
Modified: 2025-11-10
CVE-2022-49877
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues
When running `test_sockmap` selftests, the following warning appears:
WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0
Call Trace:
- https://git.kernel.org/stable/c/14e8bc3bf7bd6af64d7538a0684c8238d96cdfd7
- https://git.kernel.org/stable/c/8ec95b94716a1e4d126edc3fb2bc426a717e2dba
- https://git.kernel.org/stable/c/95adbd2ac8de82e43fd6b347e7e1b47f74dc1abb
- https://git.kernel.org/stable/c/cc21dc48a78cc9e5af9a4d039cd456446a6e73ff
- https://git.kernel.org/stable/c/d975bec1eaeb52341acc9273db79ddb078220399
Modified: 2025-10-01
CVE-2022-49878
In the Linux kernel, the following vulnerability has been resolved: bpf, verifier: Fix memory leak in array reallocation for stack state If an error (NULL) is returned by krealloc(), callers of realloc_array() were setting their allocation pointers to NULL, but on error krealloc() does not touch the original allocation. This would result in a memory resource leak. Instead, free the old allocation on the error handling path. The memory leak information is as follows as also reported by Zhengchao: unreferenced object 0xffff888019801800 (size 256): comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0 [<0000000086712a0b>] krealloc+0x83/0xd0 [<00000000139aab02>] realloc_array+0x82/0xe2 [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186 [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341 [<0000000081780455>] do_check_common+0x5358/0xb350 [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d [<000000002973c690>] bpf_prog_load+0x13db/0x2240 [<00000000028d1644>] __sys_bpf+0x1605/0x4ce0 [<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0 [<0000000056fedaf5>] do_syscall_64+0x35/0x80 [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Modified: 2025-11-10
CVE-2022-49879
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix BUG_ON() when directory entry has invalid rec_len
The rec_len field in the directory entry has to be a multiple of 4. A
corrupted filesystem image can be used to hit a BUG() in
ext4_rec_len_to_disk(), called from make_indexed_dir().
------------[ cut here ]------------
kernel BUG at fs/ext4/ext4.h:2413!
...
RIP: 0010:make_indexed_dir+0x53f/0x5f0
...
Call Trace:
- https://git.kernel.org/stable/c/156451a67b93986fb07c274ef6995ff40766c5ad
- https://git.kernel.org/stable/c/17a0bc9bd697f75cfdf9b378d5eb2d7409c91340
- https://git.kernel.org/stable/c/2fa24d0274fbf913b56ee31f15bc01168669d909
- https://git.kernel.org/stable/c/999cff2b6ce3b45c08abf793bf55534777421327
- https://git.kernel.org/stable/c/ce1ee2c8827fb6493e91acbd50f664cf2a972c3d
Modified: 2025-10-01
CVE-2022-49880
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in 'ext4_da_release_space'
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0a43c015e98121c91a76154edf42280ce1a8a883
- https://git.kernel.org/stable/c/0de5ee103747fd3a24f1c010c79caabe35e8f0bb
- https://git.kernel.org/stable/c/1b8f787ef547230a3249bcf897221ef0cc78481b
- https://git.kernel.org/stable/c/5370b965b7a945bb8f48b9ee23d83a76a947902e
- https://git.kernel.org/stable/c/72743d5598b9096950bbfd6a9b7f173d156eea97
- https://git.kernel.org/stable/c/890d738f569fa9412b70ba09f15407f17a52da20
- https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6
- https://git.kernel.org/stable/c/c3bf1e95cfa7d950dc3c064d0c2e3d06b427bc63
Modified: 2025-10-01
CVE-2022-49881
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix memory leak in query_regdb_file() In the function query_regdb_file() the alpha2 parameter is duplicated using kmemdup() and subsequently freed in regdb_fw_cb(). However, request_firmware_nowait() can fail without calling regdb_fw_cb() and thus leak memory.
- https://git.kernel.org/stable/c/0ede1a988299e95d54bd89551fd635980572e920
- https://git.kernel.org/stable/c/219446396786330937bcd382a7bc4ccd767383bc
- https://git.kernel.org/stable/c/38c9fa2cc6bf4b6e1a74057aef8b5cffd23d3264
- https://git.kernel.org/stable/c/57b962e627ec0ae53d4d16d7bd1033e27e67677a
- https://git.kernel.org/stable/c/e1e12180321f416d83444f2cdc9259e0f5093d35
- https://git.kernel.org/stable/c/e9b5a4566d5bc71cc901be50d1fa24da00613120
Modified: 2025-10-01
CVE-2022-49885
In the Linux kernel, the following vulnerability has been resolved:
ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()
Change num_ghes from int to unsigned int, preventing an overflow
and causing subsequent vmalloc() to fail.
The overflow happens in ghes_estatus_pool_init() when calculating
len during execution of the statement below as both multiplication
operands here are signed int:
len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);
The following call trace is observed because of this bug:
[ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1
[ 9.317131] Call Trace:
[ 9.317134]
Modified: 2025-10-01
CVE-2022-49887
In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix possible refcount leak in vdec_probe() v4l2_device_unregister need to be called to put the refcount got by v4l2_device_register when vdec_probe fails or vdec_remove is called.
- https://git.kernel.org/stable/c/0457e7b12ece1a7e41fa0ae8b7e47c0a72a83bef
- https://git.kernel.org/stable/c/70119756311a0be3b95bec2e1ba714673e90feba
- https://git.kernel.org/stable/c/7718999356234d9cc6a11b4641bb773928f1390f
- https://git.kernel.org/stable/c/be6e22f54623d8a856a4f167b25be73c2ff1ff80
- https://git.kernel.org/stable/c/f96ad391d054bd5c36994f98afd6a12cbb5600bf
Modified: 2025-05-07
CVE-2022-49888
In the Linux kernel, the following vulnerability has been resolved: arm64: entry: avoid kprobe recursion The cortex_a76_erratum_1463225_debug_handler() function is called when handling debug exceptions (and synchronous exceptions from BRK instructions), and so is called when a probed function executes. If the compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it can be probed. If cortex_a76_erratum_1463225_debug_handler() is probed, any debug exception or software breakpoint exception will result in recursive exceptions leading to a stack overflow. This can be triggered with the ftrace multiple_probes selftest, and as per the example splat below. This is a regression caused by commit: 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround") ... which removed the NOKPROBE_SYMBOL() annotation associated with the function. My intent was that cortex_a76_erratum_1463225_debug_handler() would be inlined into its caller, el1_dbg(), which is marked noinstr and cannot be probed. Mark cortex_a76_erratum_1463225_debug_handler() as __always_inline to ensure this. Example splat prior to this patch (with recursive entries elided): | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events | # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable | Insufficient stack space to handle exception! | ESR: 0x0000000096000047 -- DABT (current EL) | FAR: 0xffff800009cefff0 | Task stack: [0xffff800009cf0000..0xffff800009cf4000] | IRQ stack: [0xffff800008000000..0xffff800008004000] | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0] | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arm64_enter_el1_dbg+0x4/0x20 | lr : el1_dbg+0x24/0x5c | sp : ffff800009cf0000 | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068 | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0 | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4 | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040 | Kernel panic - not syncing: kernel stack overflow | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xe4/0x104 | show_stack+0x18/0x4c | dump_stack_lvl+0x64/0x7c | dump_stack+0x18/0x38 | panic+0x14c/0x338 | test_taint+0x0/0x2c | panic_bad_stack+0x104/0x118 | handle_bad_stack+0x34/0x48 | __bad_stack+0x78/0x7c | arm64_enter_el1_dbg+0x4/0x20 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | do_el0_svc+0x0/0x28 | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x18c/0x190 | Kernel Offset: disabled | CPU features: 0x0080,00005021,19001080 | Memory Limit: none | ---[ end Kernel panic - not syncing: kernel stack overflow ]--- With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined into el1_dbg(), and el1_dbg() cannot be probed: | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | sh: write error: No such file or directory | # grep -w cortex_a76_errat ---truncated---
Modified: 2025-10-01
CVE-2022-49890
In the Linux kernel, the following vulnerability has been resolved: capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |-- *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks]
- https://git.kernel.org/stable/c/0c3e6288da650d1ec911a259c77bc2d88e498603
- https://git.kernel.org/stable/c/2de8eec8afb75792440b8900a01d52b8f6742fd1
- https://git.kernel.org/stable/c/6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85
- https://git.kernel.org/stable/c/7480aeff0093d8c54377553ec6b31110bea37b4d
- https://git.kernel.org/stable/c/8cf0a1bc12870d148ae830a4ba88cfdf0e879cee
- https://git.kernel.org/stable/c/90577bcc01c4188416a47269f8433f70502abe98
- https://git.kernel.org/stable/c/cdf01c807e974048c43c7fd3ca574f6086a57906
Modified: 2025-10-01
CVE-2022-49891
In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd() test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in test_gen_kretprobe_cmd(). unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Modified: 2025-05-07
CVE-2022-49892
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1] BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...]
Modified: 2025-11-10
CVE-2022-49898
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix tree mod log mishandling of reallocated nodes We have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40 Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); This occurs because we replay the nodes in order that they happened, and when we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot, starting at 0. 'n' here is the number of items in this block, which in this case was 1, but we had 2 REMOVE_WHILE_FREEING operations. The actual root cause of this was that we were replaying operations for a block that shouldn't have been replayed. Consider the following sequence of events 1. We have an already modified root, and we do a btrfs_get_tree_mod_seq(). 2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots. 3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node. 4. We modify a new root, and re-allocate the above node to the root node of this other root. The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8 >From here the bug is triggered by the following steps 1. Call btrfs_get_old_root() on the new_root. 2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0. 3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE. 4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e ---truncated---
Modified: 2025-10-01
CVE-2022-49899
In the Linux kernel, the following vulnerability has been resolved: fscrypt: stop using keyrings subsystem for fscrypt_master_key The approach of fs/crypto/ internally managing the fscrypt_master_key structs as the payloads of "struct key" objects contained in a "struct key" keyring has outlived its usefulness. The original idea was to simplify the code by reusing code from the keyrings subsystem. However, several issues have arisen that can't easily be resolved: - When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free. - When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore. - More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped. - Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done. The fix for all these issues is to change the implementation to what I should have done originally: don't use the keyrings subsystem to keep track of the filesystem's fscrypt_master_key structs. Instead, just store them in a regular kernel data structure, and rework the reference counting, locking, and lifetime accordingly. Retain support for RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free() with fscrypt_sb_delete(), which releases the keys synchronously and runs a bit earlier during unmount, so that block devices are still available. A side effect of this patch is that neither the master keys themselves nor the filesystem keyrings will be listed in /proc/keys anymore. ("Master key users" and the master key users keyrings will still be listed.) However, this was mostly an implementation detail, and it was intended just for debugging purposes. I don't know of anyone using it. This patch does *not* change how "master key users" (->mk_users) works; that still uses the keyrings subsystem. That is still needed for key quotas, and changing that isn't necessary to solve the issues listed above. If we decide to change that too, it would be a separate patch. I've marked this as fixing the original commit that added the fscrypt keyring, but as noted above the most important issue that this patch fixes wasn't introduced until the addition of inline encryption support.
Modified: 2025-11-10
CVE-2022-49900
In the Linux kernel, the following vulnerability has been resolved:
i2c: piix4: Fix adapter not be removed in piix4_remove()
In piix4_probe(), the piix4 adapter will be registered in:
piix4_probe()
piix4_add_adapters_sb800() / piix4_add_adapter()
i2c_add_adapter()
Based on the probed device type, piix4_add_adapters_sb800() or single
piix4_add_adapter() will be called.
For the former case, piix4_adapter_count is set as the number of adapters,
while for antoher case it is not set and kept default *zero*.
When piix4 is removed, piix4_remove() removes the adapters added in
piix4_probe(), basing on the piix4_adapter_count value.
Because the count is zero for the single adapter case, the adapter won't
be removed and makes the sources allocated for adapter leaked, such as
the i2c client and device.
These sources can still be accessed by i2c or bus and cause problems.
An easily reproduced case is that if a new adapter is registered, i2c
will get the leaked adapter and try to call smbus_algorithm, which was
already freed:
Triggered by: rmmod i2c_piix4 && modprobe max31730
BUG: unable to handle page fault for address: ffffffffc053d860
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 3752 Comm: modprobe Tainted: G
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core
RSP: 0018:ffff888107477710 EFLAGS: 00000246
...
Modified: 2025-10-01
CVE-2022-49902
In the Linux kernel, the following vulnerability has been resolved: block: Fix possible memory leak for rq_wb on add_disk failure kmemleak reported memory leaks in device_add_disk(): kmemleak: 3 new suspected memory leaks unreferenced object 0xffff88800f420800 (size 512): comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s) hex dump (first 32 bytes): 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................ 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d3662699>] kmalloc_trace+0x26/0x60 [<00000000edc7aadc>] wbt_init+0x50/0x6f0 [<0000000069601d16>] wbt_enable_default+0x157/0x1c0 [<0000000028fc393f>] blk_register_queue+0x2a4/0x420 [<000000007345a042>] device_add_disk+0x6fd/0xe40 [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd] ... It is because the memory allocated in wbt_enable_default() is not released in device_add_disk() error path. Normally, these memory are freed in: del_gendisk() rq_qos_exit() rqos->ops->exit(rqos); wbt_exit() So rq_qos_exit() is called to free the rq_wb memory for wbt_init(). However in the error path of device_add_disk(), only blk_unregister_queue() is called and make rq_wb memory leaked. Add rq_qos_exit() to the error path to fix it.
Modified: 2025-11-11
CVE-2022-49903
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix WARNING in ip6_route_net_exit_late()
During the initialization of ip6_route_net_init_late(), if file
ipv6_route or rt6_stats fails to be created, the initialization is
successful by default. Therefore, the ipv6_route or rt6_stats file
doesn't be found during the remove in ip6_route_net_exit_late(). It
will cause WRNING.
The following is the stack information:
name 'rt6_stats'
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/080589287127838046077904f34d5054ea0f895c
- https://git.kernel.org/stable/c/0ed71af4d017d2bd2cbb8f7254f613a4914def26
- https://git.kernel.org/stable/c/381453770f731f0f43616a1cd4c759b7807a1517
- https://git.kernel.org/stable/c/5dbb47ee89762da433cd8458788d7640c85f1a07
- https://git.kernel.org/stable/c/768b3c745fe5789f2430bdab02f35a9ad1148d97
- https://git.kernel.org/stable/c/83fbf246ced54dadd7b9adc2a16efeff30ba944d
Modified: 2025-10-01
CVE-2022-49904
In the Linux kernel, the following vulnerability has been resolved:
net, neigh: Fix null-ptr-deref in neigh_table_clear()
When IPv6 module gets initialized but hits an error in the middle,
kenel panic with:
KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]
CPU: 1 PID: 361 Comm: insmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370
RSP: 0018:ffff888012677908 EFLAGS: 00000202
...
Call Trace:
- https://git.kernel.org/stable/c/0d38b4ca6679e72860ff8730e79bb99d0e9fa3b0
- https://git.kernel.org/stable/c/1c89642e7f2b7ecc9635610653f5c2f0276c0051
- https://git.kernel.org/stable/c/2b45d6d0c41cb9593868e476681efb1aae5078a1
- https://git.kernel.org/stable/c/a99a8ec4c62180c889482a2ff6465033e0743458
- https://git.kernel.org/stable/c/b49f6b2f21f543d4dc88fb7b1ec2adccb822f27c
- https://git.kernel.org/stable/c/b736592de2aa53aee2d48d6b129bc0c892007bbe
- https://git.kernel.org/stable/c/f8017317cb0b279b8ab98b0f3901a2e0ac880dad
Modified: 2025-11-11
CVE-2022-49905
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible leaked pernet namespace in smc_init()
In smc_init(), register_pernet_subsys(&smc_net_stat_ops) is called
without any error handling.
If it fails, registering of &smc_net_ops won't be reverted.
And if smc_nl_init() fails, &smc_net_stat_ops itself won't be reverted.
This leaves wild ops in subsystem linkedlist and when another module
tries to call register_pernet_operations() it triggers page fault:
BUG: unable to handle page fault for address: fffffbfff81b964c
RIP: 0010:register_pernet_operations+0x1b9/0x5f0
Call Trace:
Modified: 2025-10-01
CVE-2022-49906
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Free rwi on reset success Free the rwi structure in the event that the last rwi in the list processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") introduces an issue that results in a 32 byte memory leak whenever the last rwi in the list gets processed.
Modified: 2025-11-11
CVE-2022-49907
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix undefined behavior in bit shift for __mdiobus_register
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/20ed01a7b9af6e6a3c33761eebbb710ea6dd49b7
- https://git.kernel.org/stable/c/40e4eb324c59e11fcb927aa46742d28aba6ecb8a
- https://git.kernel.org/stable/c/4954b5359eb141499492fadfab891e28905509e2
- https://git.kernel.org/stable/c/634f066d02bdb22a26da7deb0c7617ab1a65fc9d
- https://git.kernel.org/stable/c/6ce6f8f8f6316da6f92afe7490bc2f0b654d68e0
- https://git.kernel.org/stable/c/7006176a3c863e3e353ce1b8a349ef5bb1b9320e
- https://git.kernel.org/stable/c/985a88bf0b27193522bba7856b1763f428cef19d
- https://git.kernel.org/stable/c/a3fafc974be37319679f36dc4e7cca7db1e02973
Modified: 2025-10-01
CVE-2022-49908
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix memory leak in vhci_write
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810d81ac00 (size 240):
[...]
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
Modified: 2025-11-11
CVE-2022-49910
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
Fix the race condition between the following two flows that run in
parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).
Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
- https://git.kernel.org/stable/c/03af22e23b96fb7ef75fb7885407ef457e8b403d
- https://git.kernel.org/stable/c/3aff8aaca4e36dc8b17eaa011684881a80238966
- https://git.kernel.org/stable/c/4cd094fd5d872862ca278e15b9b51b07e915ef3f
- https://git.kernel.org/stable/c/6c7407bfbeafc80a04e6eaedcf34d378532a04f2
- https://git.kernel.org/stable/c/8278a87bb1eeea94350d675ef961ee5a03341fde
- https://git.kernel.org/stable/c/9a04161244603f502c6e453913e51edd59cb70c1
- https://git.kernel.org/stable/c/cb1c012099ef5904cd468bdb8d6fcdfdd9bcb569
- https://git.kernel.org/stable/c/dc30e05bb18852303084430c03ca76e69257d9ea
Modified: 2025-11-11
CVE-2022-49911
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: enforce documented limit to prevent allocating huge memory
Daniel Xu reported that the hash:net,iface type of the ipset subsystem does
not limit adding the same network with different interfaces to a set, which
can lead to huge memory usage or allocation failure.
The quick reproducer is
$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0
$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done
The backtrace when vmalloc fails:
[Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages
<...>
[Tue Oct 25 00:13:08 2022] Call Trace:
[Tue Oct 25 00:13:08 2022]
Modified: 2025-11-12
CVE-2022-49912
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix ulist leaks in error paths of qgroup self tests In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests, if we fail to add the tree ref, remove the extent item or remove the extent ref, we are returning from the test function without freeing the "old_roots" ulist that was allocated by the previous calls to btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
- https://git.kernel.org/stable/c/0a0dead4ad1a2e2a9bdf133ef45111d7c8daef84
- https://git.kernel.org/stable/c/203204798831c35d855ecc6417d98267d2d2184b
- https://git.kernel.org/stable/c/3f58283d83a588ff5da62fc150de19e798ed2ec2
- https://git.kernel.org/stable/c/5d1a47ebf84540e40b5b43fc21aef0d6c0f627d9
- https://git.kernel.org/stable/c/d37de92b38932d40e4a251e876cc388f9aee5f42
- https://git.kernel.org/stable/c/d81370396025cf63a7a1b5f8bb25a3479203b2ca
- https://git.kernel.org/stable/c/da7003434bcab0ae9aba3f2c003e734cae093326
- https://git.kernel.org/stable/c/f46ea5fa3320dca4fe0c0926b49a5f14cb85de62
Modified: 2025-11-12
CVE-2022-49913
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at find_parent_nodes() During backref walking, at find_parent_nodes(), if we are dealing with a data extent and we get an error while resolving the indirect backrefs, at resolve_indirect_refs(), or in the while loop that iterates over the refs in the direct refs rbtree, we end up leaking the inode lists attached to the direct refs we have in the direct refs rbtree that were not yet added to the refs ulist passed as argument to find_parent_nodes(). Since they were not yet added to the refs ulist and prelim_release() does not free the lists, on error the caller can only free the lists attached to the refs that were added to the refs ulist, all the remaining refs get their inode lists never freed, therefore leaking their memory. Fix this by having prelim_release() always free any attached inode list to each ref found in the rbtree, and have find_parent_nodes() set the ref's inode list to NULL once it transfers ownership of the inode list to a ref added to the refs ulist passed to find_parent_nodes().
- https://git.kernel.org/stable/c/222a3d533027b9492d5b7f5ecdc01a90f57bb5a9
- https://git.kernel.org/stable/c/61e06128113711df0534c404fb6bb528eb7d2332
- https://git.kernel.org/stable/c/6a6731a0df8c47ecc703bd7bb73459df767051e0
- https://git.kernel.org/stable/c/83ea8c5b54d452a5769e605e3c5c687e8ca06d89
- https://git.kernel.org/stable/c/92876eec382a0f19f33d09d2c939e9ca49038ae5
Modified: 2025-11-12
CVE-2022-49914
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at resolve_indirect_refs() During backref walking, at resolve_indirect_refs(), if we get an error we jump to the 'out' label and call ulist_free() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the unodes. Fix this by calling free_leaf_list() instead of ulist_free() when we exit from resolve_indirect_refs(). The static function free_leaf_list() is moved up for this to be possible and it's slightly simplified by removing unnecessary code.
- https://git.kernel.org/stable/c/2c0329406bb28109c07c6e23e5e3e0fa618a95d7
- https://git.kernel.org/stable/c/396515db923ad5cbeb179d6b88927870b4cbebb7
- https://git.kernel.org/stable/c/5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1
- https://git.kernel.org/stable/c/6ba3479f9e96b9ad460c7e77abc26dd16e5dec4f
- https://git.kernel.org/stable/c/a52e24c7fcc3c5ce3588a14e3663c00868d36623
- https://git.kernel.org/stable/c/b1dc9019bb5f89abae85645de1a2dd4830c1f8e9
- https://git.kernel.org/stable/c/cded2c89774b99b67c98147ae103ea878c92a206
Modified: 2025-10-01
CVE-2022-49915
In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release().
- https://git.kernel.org/stable/c/029d5b7688a2f3a86f2a3be5a6ba9cc968c80e41
- https://git.kernel.org/stable/c/080aabfb29b2ee9cbb8894a1d039651943d3773e
- https://git.kernel.org/stable/c/0d4e91efcaee081e919b3c50e875ecbb84290e41
- https://git.kernel.org/stable/c/2ff6b669523d3b3d253a044fa9636a67d0694995
- https://git.kernel.org/stable/c/a636fc5a7cabd05699b5692ad838c2c7a3abec7b
- https://git.kernel.org/stable/c/d1d1aede313eb2b9a84afd60ff6cfb7c33631e0e
- https://git.kernel.org/stable/c/e77d213843e67b4373285712699b692f9c743f61
- https://git.kernel.org/stable/c/e7d1d4d9ac0dfa40be4c2c8abd0731659869b297
Modified: 2025-10-01
CVE-2022-49916
In the Linux kernel, the following vulnerability has been resolved:
rose: Fix NULL pointer dereference in rose_send_frame()
The syzkaller reported an issue:
KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: rcu_gp srcu_invoke_callbacks
RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
Call Trace:
- https://git.kernel.org/stable/c/01b9c68c121847d05a4ccef68244dadf82bfa331
- https://git.kernel.org/stable/c/3e2129c67daca21043a26575108f6286c85e71f6
- https://git.kernel.org/stable/c/5b46adfbee1e429f33b10a88d6c00fa88f3d6c77
- https://git.kernel.org/stable/c/a601e5eded33bb88b8a42743db8fef3ad41dd97e
- https://git.kernel.org/stable/c/b13be5e852b03f376058027e462fad4230240891
- https://git.kernel.org/stable/c/bbc03d74e641e824754443b908454ca9e203773e
- https://git.kernel.org/stable/c/e97c089d7a49f67027395ddf70bf327eeac2611e
- https://git.kernel.org/stable/c/f06186e5271b980bac03f5c97276ed0146ddc9b0
Modified: 2025-11-12
CVE-2022-49917
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in ip_vs_app_net_cleanup()
During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn't be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.
The following is the stack information:
name 'ip_vs_app'
WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/06d7596d18725f1a93cf817662d36050e5afb989
- https://git.kernel.org/stable/c/2c8d81bdb2684d53d6cedad7410ba4cf9090e343
- https://git.kernel.org/stable/c/5663ed63adb9619c98ab7479aa4606fa9b7a548c
- https://git.kernel.org/stable/c/8457a00c981fe1a799ce34123908856b0f5973b8
- https://git.kernel.org/stable/c/97f872b00937f2689bff2dab4ad9ed259482840f
- https://git.kernel.org/stable/c/adc76740ccd52e4a1d910767cd1223e134a7078b
Modified: 2025-11-12
CVE-2022-49918
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in __ip_vs_cleanup_batch()
During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
or ip_vs_conn_sync fails to be created, the initialization is successful
by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
be found during the remove.
The following is the stack information:
name 'ip_vs_conn_sync'
WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712
remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/3d00c6a0da8ddcf75213e004765e4a42acc71d5d
- https://git.kernel.org/stable/c/5ee2d6b726b0ce339e36569e5849692f4cf4595e
- https://git.kernel.org/stable/c/7effc4ce3d1434ce6ff286866585a6e905fdbfc1
- https://git.kernel.org/stable/c/931f56d59c854263b32075bfac56fdb3b1598d1b
- https://git.kernel.org/stable/c/e724220b826e008764309d2a1f55a9434a4e1530
- https://git.kernel.org/stable/c/f08ee2aa24c076f81d84e26e213d8c6f4efd9f50
Modified: 2025-10-01
CVE-2022-49919
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flow rule object from commit path No need to postpone this to the commit release path, since no packets are walking over this object, this is accessed from control plane only. This helped uncovered UAF triggered by races with the netlink notifier.
- https://git.kernel.org/stable/c/26b5934ff4194e13196bedcba373cd4915071d0e
- https://git.kernel.org/stable/c/4ab6f96444e936f5e4a936d5c0bc948144bcded3
- https://git.kernel.org/stable/c/6044791b7be707fd0e709f26e961a446424e5051
- https://git.kernel.org/stable/c/74fd5839467054cd9c4d050614d3ee8788386171
- https://git.kernel.org/stable/c/b2d7a92aff0fbd93c29d2aa6451fb99f050e2c4e
Modified: 2025-10-01
CVE-2022-49920
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: netlink notifier might race to release objects commit release path is invoked via call_rcu and it runs lockless to release the objects after rcu grace period. The netlink notifier handler might win race to remove objects that the transaction context is still referencing from the commit release path. Call rcu_barrier() to ensure pending rcu callbacks run to completion if the list of transactions to be destroyed is not empty.
Modified: 2025-10-01
CVE-2022-49921
In the Linux kernel, the following vulnerability has been resolved: net: sched: Fix use after free in red_enqueue() We can't use "skb" again after passing it to qdisc_enqueue(). This is basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb len before calling child enqueue").
- https://git.kernel.org/stable/c/170e5317042c302777ed6d59fdb84af9b0219d4e
- https://git.kernel.org/stable/c/52e0429471976785c155bfbf51d80990c6cd46e2
- https://git.kernel.org/stable/c/5960b9081baca85cc7dcb14aec1de85999ea9d36
- https://git.kernel.org/stable/c/795afe0b9bb6c915f0299a8e309936519be01619
- https://git.kernel.org/stable/c/8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9
- https://git.kernel.org/stable/c/a238cdcf2bdc72207c74375fc8be13ee549ca9db
- https://git.kernel.org/stable/c/e877f8fa49fbccc63cb2df2e9179bddc695b825a
- https://git.kernel.org/stable/c/fc4b50adb400ee5ec527a04073174e8e73a139fa
Modified: 2025-10-01
CVE-2022-49922
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() will only free skb when i2c_master_send() return >=0, which means skb will memleak when i2c_master_send() failed. Free skb no matter whether i2c_master_send() succeeds.
- https://git.kernel.org/stable/c/52438e734c1566f5e2bcd9a065d2d65e306c0555
- https://git.kernel.org/stable/c/5dfdac5e3f8db5f4445228c44f64091045644a3b
- https://git.kernel.org/stable/c/825656ae61e73ddc05f585e6258d284c87064b10
- https://git.kernel.org/stable/c/92a1df9c6da20c02cf9872f8b025a66ddb307aeb
- https://git.kernel.org/stable/c/93d904a734a74c54d945a9884b4962977f1176cd
- https://git.kernel.org/stable/c/c8e7d4a1166f063703955f1b2e765a6db5bf1771
- https://git.kernel.org/stable/c/dd0ee55ead91fbb16889dbe7ff0b0f7c9e4e849d
- https://git.kernel.org/stable/c/f30060efcf18883748a0541aa41acef183cd9c0e
Modified: 2025-10-01
CVE-2022-49923
In the Linux kernel, the following vulnerability has been resolved: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds.
Modified: 2025-10-01
CVE-2022-49924
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: Fix potential memory leak in fdp_nci_send() fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in the function. As a result, when fdp_nci_i2c_write() finished, the skb will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() finished.
Modified: 2025-10-01
CVE-2022-49925
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
- https://git.kernel.org/stable/c/07c0d131cc0fe1f3981a42958fc52d573d303d89
- https://git.kernel.org/stable/c/6b3d5dcb12347f3518308c2c9d2cf72453a3e1e5
- https://git.kernel.org/stable/c/ab817f75e5e0fa58d9be0825da6a7b7d8a1fa1d9
- https://git.kernel.org/stable/c/af8fb5a0600e9ae29950e9422a032c3c22649ee5
- https://git.kernel.org/stable/c/d360e875c011a005628525bf290322058927e7dc
Modified: 2025-10-01
CVE-2022-49926
In the Linux kernel, the following vulnerability has been resolved: net: dsa: Fix possible memory leaks in dsa_loop_init() kmemleak reported memory leaks in dsa_loop_init(): kmemleak: 12 new suspected memory leaks unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ... There are two reasons for memleak in dsa_loop_init(). First, fixed_phy_register() create and register phy_device: fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove() But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked. Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs. Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.
- https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e
- https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254
- https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50
- https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3
- https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7
- https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f
- https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c
Modified: 2025-10-01
CVE-2022-49927
In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/24641993a7dce6b1628645f4e1d97ca06c9f765d
- https://git.kernel.org/stable/c/45aea4fbf61e205649c29200726b9f45c1718a67
- https://git.kernel.org/stable/c/7e8436728e22181c3f12a5dbabd35ed3a8b8c593
- https://git.kernel.org/stable/c/84b5cb476903003ae9ca88f32b57ff0eaefa6d4c
- https://git.kernel.org/stable/c/86ce0e93cf6fb4d0c447323ac66577c642628b9d
- https://git.kernel.org/stable/c/925cb538bd5851154602818dc80bf4b4d924c127
- https://git.kernel.org/stable/c/aae35a0c8a775fa4afa6a4e7dab3f936f1f89bbb
- https://git.kernel.org/stable/c/db333ae981fb8843c383aa7dbf62cc682597d401
Modified: 2025-10-01
CVE-2022-49928
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed
There is a null-ptr-deref when xps sysfs alloc failed:
BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0
Read of size 8 at addr 0000000000000030 by task gssproxy/457
CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9
Call Trace:
Modified: 2025-10-01
CVE-2022-49931
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list.
- https://git.kernel.org/stable/c/1afac08b39d85437187bb2a92d89a741b1078f55
- https://git.kernel.org/stable/c/25760a41e3802f54aadcc31385543665ab349b8e
- https://git.kernel.org/stable/c/7c4260f8f188df32414a5ecad63e8b934c2aa3f0
- https://git.kernel.org/stable/c/b8bcff99b07cc175a6ee12a52db51cdd2229586c
- https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926
Modified: 2025-11-24
CVE-2022-50234
In the Linux kernel, the following vulnerability has been resolved: io_uring/af_unix: defer registered files gc to io_uring release Instead of putting io_uring's registered files in unix_gc() we want it to be done by io_uring itself. The trick here is to consider io_uring registered files for cycle detection but not actually putting them down. Because io_uring can't register other ring instances, this will remove all refs to the ring file triggering the ->release path and clean up with io_ring_ctx_free(). [axboe: add kerneldoc comment to skb, fold in skb leak fix]
- https://git.kernel.org/stable/c/0091bfc81741b8d3aeb3b7ab8636f911b2de6e80
- https://git.kernel.org/stable/c/04df9719df1865f6770af9bc7880874af0e594b2
- https://git.kernel.org/stable/c/75e94c7e8859e58aadc15a98cc9704edff47d4f2
- https://git.kernel.org/stable/c/813d8fe5d30388f73a21d3a2bf46b0a1fd72498c
- https://git.kernel.org/stable/c/b4293c01ee0d0ecdd3cb5801e13f62271144667a
- https://git.kernel.org/stable/c/c378c479c5175833bb22ff71974cda47d7b05401
Modified: 2025-11-24
CVE-2022-50235
In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer overflow in NFSv2 READDIR Restore the previous limit on the @count argument to prevent a buffer overflow attack.
- https://git.kernel.org/stable/c/00b4492686e0497fdb924a9d4c8f6f99377e176c
- https://git.kernel.org/stable/c/0e57d696f60dee6117a8ace0cac7c5761d375277
- https://git.kernel.org/stable/c/c2a878095b5c6f04f90553a3c45872f990dab14e
- https://git.kernel.org/stable/c/dc7f225090c29a5f3b9419b1af32846a201555e7
- https://git.kernel.org/stable/c/f59c74df82f6ac9d2ea4e01aa3ae7c6c4481652d
Modified: 2025-11-24
CVE-2022-50239
In the Linux kernel, the following vulnerability has been resolved: cpufreq: qcom: fix writes in read-only memory region This commit fixes a kernel oops because of a write in some read-only memory: [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8 ..snip.. [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP ..snip.. [ 9.269161] Call trace: [ 9.276271] __memcpy+0x5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190 [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c ..snip.. The following line defines a pointer that point to a char buffer stored in read-only memory: char *pvs_name = "speedXX-pvsXX-vXX"; This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the XX values get overridden by the qcom_cpufreq_krait_name_version function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops: snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d", speed, pvs, pvs_ver); To fix this issue, we instead store the template name onto the stack by using the following syntax: char pvs_name_buffer[] = "speedXX-pvsXX-vXX"; Because the `pvs_name` needs to be able to be assigned to NULL, the template buffer is stored in the pvs_name_buffer and not under the pvs_name variable.
Modified: 2025-11-25
CVE-2022-50241
In the Linux kernel, the following vulnerability has been resolved: NFSD: fix use-after-free on source server when doing inter-server copy Use-after-free occurred when the laundromat tried to free expired cpntf_state entry on the s2s_cp_stateids list after inter-server copy completed. The sc_cp_list that the expired copy state was inserted on was already freed. When COPY completes, the Linux client normally sends LOCKU(lock_state x), FREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server. The nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state from the s2s_cp_stateids list before freeing the lock state's stid. However, sometimes the CLOSE was sent before the FREE_STATEID request. When this happens, the nfsd4_close_open_stateid call from nfsd4_close frees all lock states on its st_locks list without cleaning up the copy state on the sc_cp_list list. When the time the FREE_STATEID arrives the server returns BAD_STATEID since the lock state was freed. This causes the use-after-free error to occur when the laundromat tries to free the expired cpntf_state. This patch adds a call to nfs4_free_cpntf_statelist in nfsd4_close_open_stateid to clean up the copy state before calling free_ol_stateid_reaplist to free the lock state's stid on the reaplist.
- https://git.kernel.org/stable/c/019805fea91599b22dfa62ffb29c022f35abeb06
- https://git.kernel.org/stable/c/35aa0fb8c3033a3d78603356e96fc18c5b9cceb2
- https://git.kernel.org/stable/c/6ea71246b7a02af675d733e72d14bd0d591d5f4a
- https://git.kernel.org/stable/c/83b94969751a691347606dbe6b1865efcfa5a643
- https://git.kernel.org/stable/c/bbacfcde5fff25ac22597e8373a065c647da6738
Modified: 2025-11-24
CVE-2022-50242
In the Linux kernel, the following vulnerability has been resolved: drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init() If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp needs to be freed.
- https://git.kernel.org/stable/c/01de1123322e4fe1bbd0fcdf0982511b55519c03
- https://git.kernel.org/stable/c/0aefadf23ee5e33b747df195ace42d3be2025e4e
- https://git.kernel.org/stable/c/132c502919bb08e16e3054cb28bb7b149ec20cf5
- https://git.kernel.org/stable/c/14b349a15c297cf3e01b5deb4116f7cf297b6184
- https://git.kernel.org/stable/c/15770edc01edfce773269e8a443ca8e420f6f859
- https://git.kernel.org/stable/c/8399b9893548c03fdb18be277bf99d985dbde925
- https://git.kernel.org/stable/c/a44490abaf00f5b0cc5c448a17eae331c6195d0a
- https://git.kernel.org/stable/c/aa2d179544b6815b4a23c0c44543ba0971d49fce
- https://git.kernel.org/stable/c/dcae92a249551d1a447804b4be1c9fab0e8c95e8
Modified: 2025-11-24
CVE-2022-50243
In the Linux kernel, the following vulnerability has been resolved: sctp: handle the error returned from sctp_auth_asoc_init_active_key When it returns an error from sctp_auth_asoc_init_active_key(), the active_key is actually not updated. The old sh_key will be freeed while it's still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 This patch is to fix it by not replacing the sh_key when it returns errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key(). For sctp_auth_set_active_key(), old active_key_id will be set back to asoc->active_key_id when the same thing happens.
- https://git.kernel.org/stable/c/022152aaebe116a25c39818a07e175a8cd3c1e11
- https://git.kernel.org/stable/c/0f90099d18e3abdc01babf686f41f63fe04939c1
- https://git.kernel.org/stable/c/19d636b663e0e92951bba5fced929ca7fd25c552
- https://git.kernel.org/stable/c/382ff44716603a54f5fd238ddec6a2468e217612
- https://git.kernel.org/stable/c/3b0fcf5e29c0940e1169ce9c44f73edd98bdf12d
- https://git.kernel.org/stable/c/b8fa99a3a11bdd77fef6b4a97f1021eb30b5ba40
- https://git.kernel.org/stable/c/f65955340e0044f5c41ac799a01698ac7dee8a4e
Modified: 2025-11-24
CVE-2022-50244
In the Linux kernel, the following vulnerability has been resolved: cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter() If device_register() fails in cxl_pci_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails.
- https://git.kernel.org/stable/c/02cd3032b154fa02fdf90e7467abaeed889330b2
- https://git.kernel.org/stable/c/0f63c0ddc2ea20d783d29243f4dbe0f9e95dfdec
- https://git.kernel.org/stable/c/139abd4c626a6f7ce02789ed5f73aa2256e0542b
- https://git.kernel.org/stable/c/22511eefa61db26e12c97dd7ada3071dbdfcb004
- https://git.kernel.org/stable/c/2f5fd31b2f24b9b8a80ab566fd8c4e1e94cb4339
- https://git.kernel.org/stable/c/361412dae1690d4b5df6f92fc943cdc773c95cbc
- https://git.kernel.org/stable/c/82e5481428faf11c79b9c094dd24a1849bbf64ac
- https://git.kernel.org/stable/c/82e68432668ae75b4c814d160f6987ecb0681273
- https://git.kernel.org/stable/c/c4b2e35df919d99bbbed033c2fa0b607f9f463b5
Modified: 2025-11-24
CVE-2022-50245
In the Linux kernel, the following vulnerability has been resolved: rapidio: fix possible UAF when kfifo_alloc() fails If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free priv. But priv is still in the chdev->file_list, then list traversal may cause UAF. This fixes the following smatch warning: drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: '&priv->list' not removed from list
- https://git.kernel.org/stable/c/02d7d89f816951e0862147d751b1150d67aaebdd
- https://git.kernel.org/stable/c/2a6c75adf8192f07ddcdd4a1a13488c890a73919
- https://git.kernel.org/stable/c/2ba06e57f933f0eac242e8b389433da1cc00d4d5
- https://git.kernel.org/stable/c/2dfd60724d271a6ab99f93f40f38f2ced1ddbb87
- https://git.kernel.org/stable/c/2f5cc7fd73fd6253cc71214f0dd499cc62feb469
- https://git.kernel.org/stable/c/311b488405ac45af46756b1c8f1d27007b68b07e
- https://git.kernel.org/stable/c/5ee850645e42f541ce1ea8130c2b27cc495f965c
- https://git.kernel.org/stable/c/a253dde0403a153075ffb254f6f7b2635e49e97a
- https://git.kernel.org/stable/c/cb87af2c19c0993f6e21f75b963a5599c5a73e76
Modified: 2025-11-24
CVE-2022-50246
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpci: fix of node refcount leak in tcpci_register_port() I got the following report while doing device(mt6370-tcpc) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@34/tcpc/connector The 'fwnode' set in tcpci_parse_config() which is called in tcpci_register_port(), its node refcount is increased in device_get_named_child_node(). It needs be put while exiting, so call fwnode_handle_put() in the error path of tcpci_register_port() and in tcpci_unregister_port() to avoid leak.
- https://git.kernel.org/stable/c/0384e87e3fec735e47f1c133c796f32ef7a72a9b
- https://git.kernel.org/stable/c/4f257e2eba419ab4cd880c822346450e4e7b2af3
- https://git.kernel.org/stable/c/5f125507d2270035dfcf83fbff6cff5a143e200c
- https://git.kernel.org/stable/c/ba75be6f0d9d028d20852564206565a4c03e3288
- https://git.kernel.org/stable/c/d3b6c28a71f111a6c67ddc3238aab95910fd86cf
- https://git.kernel.org/stable/c/e75a324409715bd71348f79a49aa61b69dbeb676
Modified: 2025-11-24
CVE-2022-50247
In the Linux kernel, the following vulnerability has been resolved: usb: xhci-mtk: fix leakage of shared hcd when fail to set wakeup irq Can not set the @shared_hcd to NULL before decrease the usage count by usb_put_hcd(), this will cause the shared hcd not released.
Modified: 2025-11-25
CVE-2022-50248
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix double free on tx path.
We see kernel crashes and lockups and KASAN errors related to ax210
firmware crashes. One of the KASAN dumps pointed at the tx path,
and it appears there is indeed a way to double-free an skb.
If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the
method will be freed. But, in case where we build TSO skb buffer,
the skb may also be freed in error case. So, return 0 in that particular
error case and do cleanup manually.
BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000000 | tsf hi
Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650
CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5
iwlwifi 0000:06:00.0: 0x00000000 | time gp1
Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019
Call Trace:
- https://git.kernel.org/stable/c/0473cbae2137b963bd0eaa74336131cb1d3bc6c3
- https://git.kernel.org/stable/c/0e1e311fd929c6a8dcfddcb4748c47b07e39821f
- https://git.kernel.org/stable/c/3a2ecd1ec14075117ccb3e85f0fed224578ec228
- https://git.kernel.org/stable/c/8fabe41fba907e4fd826acbbdb42e09c681c515e
- https://git.kernel.org/stable/c/ae966649f665bc3868b935157dd4a3c31810dcc0
- https://git.kernel.org/stable/c/d8e32f1bf1a9183a6aad560c6688500222d24299
Modified: 2025-11-25
CVE-2022-50249
In the Linux kernel, the following vulnerability has been resolved: memory: of: Fix refcount leak bug in of_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount.
- https://git.kernel.org/stable/c/05215fb32010d4afb68fbdbb4d237df6e2d4567b
- https://git.kernel.org/stable/c/1c6cac6fa4d08aea161f83d38117d733b3c3a000
- https://git.kernel.org/stable/c/2680690f9ce4e6abbb4f559e97271c15b7eeda97
- https://git.kernel.org/stable/c/62ccab6e3376f8a22167c3b81468ae4f3e7d25f1
- https://git.kernel.org/stable/c/68c9c4e6495b825be3a8946df1a0148399555fe4
- https://git.kernel.org/stable/c/85a40bfb8e7a170abcf9dae2c0898a1983e48daa
- https://git.kernel.org/stable/c/a4d0bd4388e1a39df47e8aaa044ef6a7ee626e48
- https://git.kernel.org/stable/c/a4f7eb83852a65b6f8dea7dcc42b7c76d4d9b0a3
- https://git.kernel.org/stable/c/daaec4b3fe2297b022c6b2d6bf48b6e5265a60b9
Modified: 2025-11-25
CVE-2022-50250
In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix use_count leakage when handling boot-on I found a use_count leakage towards supply regulator of rdev with boot-on option. ┌───────────────────┐ ┌───────────────────┐ │ regulator_dev A │ │ regulator_dev B │ │ (boot-on) │ │ (boot-on) │ │ use_count=0 │◀──supply──│ use_count=1 │ │ │ │ │ └───────────────────┘ └───────────────────┘ In case of rdev(A) configured with `regulator-boot-on', the use_count of supplying regulator(B) will increment inside regulator_enable(rdev->supply). Thus, B will acts like always-on, and further balanced regulator_enable/disable cannot actually disable it anymore. However, B was also configured with `regulator-boot-on', we wish it could be disabled afterwards.
- https://git.kernel.org/stable/c/0591b14ce0398125439c759f889647369aa616a0
- https://git.kernel.org/stable/c/4b737246ff50f810d6ab4be13c1388a07f0c14b1
- https://git.kernel.org/stable/c/4dd6e1cc9c7403f1ee1b7eee85bc31b797ae8347
- https://git.kernel.org/stable/c/5bfc53df288e8ea54ca6866fb92034214940183f
- https://git.kernel.org/stable/c/bc6c381df5793ebcf32db88a3e65acf7870379fc
- https://git.kernel.org/stable/c/dc3391d49479bc2bf8a2b88dbf86fdd800882fee
- https://git.kernel.org/stable/c/feb847e6591e8c7a09cc39721cc9ca74fd9a5d80
Modified: 2025-11-26
CVE-2022-50251
In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, the timer added before mmc_add_host() needs be del. And this patch fixes another missing call mmc_free_host() if usb_control_msg() fails.
- https://git.kernel.org/stable/c/0613ad2401f88bdeae5594c30afe318e93b14676
- https://git.kernel.org/stable/c/2044b2ea77945f372ef161d1bbf814e471767ff2
- https://git.kernel.org/stable/c/25f05d762ca5e1c685002a53dd44f68e78ca3feb
- https://git.kernel.org/stable/c/3049a3b927a40d89d4582ff1033cd7953be773c7
- https://git.kernel.org/stable/c/3b29f8769d32016b2d89183db4d80c7a71b7e35e
- https://git.kernel.org/stable/c/41ed46bdbd2878cd6567abe0974a445f8b1b8ec8
- https://git.kernel.org/stable/c/a46e681151bbdacdf6b89ee8c4e5bad0555142bb
- https://git.kernel.org/stable/c/afc898019e7bf18c5eb7a0ac19852fcb1b341b3c
- https://git.kernel.org/stable/c/c9e85979b59cb86f0a15defa8199d740e2b36b90
Modified: 2025-11-26
CVE-2022-50252
In the Linux kernel, the following vulnerability has been resolved: igb: Do not free q_vector unless new one was allocated Avoid potential use-after-free condition under memory pressure. If the kzalloc() fails, q_vector will be freed but left in the original adapter->q_vector[v_idx] array position.
- https://git.kernel.org/stable/c/0200f0fbb11e359cc35af72ab10b2ec224e6f633
- https://git.kernel.org/stable/c/0668716506ca66f90d395f36ccdaebc3e0e84801
- https://git.kernel.org/stable/c/314f7092b27749bdde44c14095b5533afa2a3bc8
- https://git.kernel.org/stable/c/3cb18dea11196fb4a06f78294cec5e61985e1aff
- https://git.kernel.org/stable/c/56483aecf6b22eb7dff6315b3a174688c6ad494c
- https://git.kernel.org/stable/c/64ca1969599857143e91aeec4440640656100803
- https://git.kernel.org/stable/c/68e8adbcaf7a8743e473343b38b9dad66e2ac6f3
- https://git.kernel.org/stable/c/6e399577bd397a517df4b938601108c63769ce0a
- https://git.kernel.org/stable/c/f96bd8adc8adde25390965a8c1ee81b73cb62075
Modified: 2025-11-26
CVE-2022-50253
In the Linux kernel, the following vulnerability has been resolved: bpf: make sure skb->len != 0 when redirecting to a tunneling device syzkaller managed to trigger another case where skb->len == 0 when we enter __dev_queue_xmit: WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline] WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295 Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6 The reproducer doesn't really reproduce outside of syzkaller environment, so I'm taking a guess here. It looks like we do generate correct ETH_HLEN-sized packet, but we redirect the packet to the tunneling device. Before we do so, we __skb_pull l2 header and arrive again at skb->len == 0. Doesn't seem like we can do anything better than having an explicit check after __skb_pull?
- https://git.kernel.org/stable/c/07ec7b502800ba9f7b8b15cb01dd6556bb41aaca
- https://git.kernel.org/stable/c/1b65704b8c08ae92db29f720d3b298031131da53
- https://git.kernel.org/stable/c/5d3f4478d22b2cb1810f6fe0f797411e9d87b3e5
- https://git.kernel.org/stable/c/6d935a02658be82585ecb39aab339faa84496650
- https://git.kernel.org/stable/c/772431f30ca040cfbf31b791d468bac6a9ca74d3
- https://git.kernel.org/stable/c/e6a63203e5a90a39392fa1a7ffc60f5e9baf642a
- https://git.kernel.org/stable/c/f186303845a01cc7e991f9dc51d7e5a3cdc7aedb
- https://git.kernel.org/stable/c/ffbccc5fb0a67424e12f7f8da210c04c8063f797
Modified: 2025-11-25
CVE-2022-50255
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix reading strings from synthetic events The follow commands caused a crash: # cd /sys/kernel/tracing # echo 's:open char file[]' > dynamic_events # echo 'hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)' > events/syscalls/sys_enter_openat/trigger' # echo 1 > events/synthetic/open/enable BOOM! The problem is that the synthetic event field "char file[]" will read the value given to it as a string without any memory checks to make sure the address is valid. The above example will pass in the user space address and the sythetic event code will happily call strlen() on it and then strscpy() where either one will cause an oops when accessing user space addresses. Use the helper functions from trace_kprobe and trace_eprobe that can read strings safely (and actually succeed when the address is from user space and the memory is mapped in). Now the above can show: packagekitd-1721 [000] ...2. 104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr in:imjournal-978 [006] ...2. 104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp packagekitd-1721 [000] ...2. 104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr
Modified: 2025-11-25
CVE-2022-50257
In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: Prevent leaking grants Prior to this commit, if a grant mapping operation failed partially, some of the entries in the map_ops array would be invalid, whereas all of the entries in the kmap_ops array would be valid. This in turn would cause the following logic in gntdev_map_grant_pages to become invalid: for (i = 0; i < map->count; i++) { if (map->map_ops[i].status == GNTST_okay) { map->unmap_ops[i].handle = map->map_ops[i].handle; if (!use_ptemod) alloced++; } if (use_ptemod) { if (map->kmap_ops[i].status == GNTST_okay) { if (map->map_ops[i].status == GNTST_okay) alloced++; map->kunmap_ops[i].handle = map->kmap_ops[i].handle; } } } ... atomic_add(alloced, &map->live_grants); Assume that use_ptemod is true (i.e., the domain mapping the granted pages is a paravirtualized domain). In the code excerpt above, note that the "alloced" variable is only incremented when both kmap_ops[i].status and map_ops[i].status are set to GNTST_okay (i.e., both mapping operations are successful). However, as also noted above, there are cases where a grant mapping operation fails partially, breaking the assumption of the code excerpt above. The aforementioned causes map->live_grants to be incorrectly set. In some cases, all of the map_ops mappings fail, but all of the kmap_ops mappings succeed, meaning that live_grants may remain zero. This in turn makes it impossible to unmap the successfully grant-mapped pages pointed to by kmap_ops, because unmap_grant_pages has the following snippet of code at its beginning: if (atomic_read(&map->live_grants) == 0) return; /* Nothing to do */ In other cases where only some of the map_ops mappings fail but all kmap_ops mappings succeed, live_grants is made positive, but when the user requests unmapping the grant-mapped pages, __unmap_grant_pages_done will then make map->live_grants negative, because the latter function does not check if all of the pages that were requested to be unmapped were actually unmapped, and the same function unconditionally subtracts "data->count" (i.e., a value that can be greater than map->live_grants) from map->live_grants. The side effects of a negative live_grants value have not been studied. The net effect of all of this is that grant references are leaked in one of the above conditions. In Qubes OS v4.1 (which uses Xen's grant mechanism extensively for X11 GUI isolation), this issue manifests itself with warning messages like the following to be printed out by the Linux kernel in the VM that had granted pages (that contain X11 GUI window data) to dom0: "g.e. 0x1234 still pending", especially after the user rapidly resizes GUI VM windows (causing some grant-mapping operations to partially or completely fail, due to the fact that the VM unshares some of the pages as part of the window resizing, making the pages impossible to grant-map from dom0). The fix for this issue involves counting all successful map_ops and kmap_ops mappings separately, and then adding the sum to live_grants. During unmapping, only the number of successfully unmapped grants is subtracted from live_grants. The code is also modified to check for negative live_grants values after the subtraction and warn the user.
- https://git.kernel.org/stable/c/0991028cd49567d7016d1b224fe0117c35059f86
- https://git.kernel.org/stable/c/0bccddd9b8f03ad57bb738f0d3da8845d4e1e579
- https://git.kernel.org/stable/c/1cb73704cb4778299609634a790a80daba582f7d
- https://git.kernel.org/stable/c/273f6a4f71be12e2ec80a4919837d6e4fa933a04
- https://git.kernel.org/stable/c/3d056d81b93a787613eda44aeb21fc14c3392b34
- https://git.kernel.org/stable/c/49bb053b1ec367b6883030eb2cca696e91435679
- https://git.kernel.org/stable/c/49db6cb81400ba863e1a85e55fcdf1031807c23f
- https://git.kernel.org/stable/c/b043f2cab100bed3e0a999dcf38cc05b1e4a7e41
- https://git.kernel.org/stable/c/cb1ccfe7655380f77a58b340072f5f40bc285902
Modified: 2025-11-25
CVE-2022-50259
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: fix race in sock_map_free()
sock_map_free() calls release_sock(sk) without owning a reference
on the socket. This can cause use-after-free as syzbot found [1]
Jakub Sitnicki already took care of a similar issue
in sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:
Synchronize delete from bucket list on map free")
[1]
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Modules linked in:
CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: events_unbound bpf_map_free_deferred
RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff
RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246
RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0
RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000
RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5
R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004
R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0a182f8d607464911756b4dbef5d6cad8de22469
- https://git.kernel.org/stable/c/4cabc3af4a6f36c222fecb15858c1060e59218e7
- https://git.kernel.org/stable/c/5c3568166129bc73fd6b37748d2d8f95cd8f22f3
- https://git.kernel.org/stable/c/a443c55d96dede82a724df6e70a318ad15c199e1
- https://git.kernel.org/stable/c/be719496ae6a7fc325e9e5056a52f63ebc84cc0c
- https://git.kernel.org/stable/c/e8b2b392a646bf5cb9413c1cc7a39d99c1b65a62
Modified: 2025-11-25
CVE-2022-50261
In the Linux kernel, the following vulnerability has been resolved: drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid() With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hda_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_dvo_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hdmi_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to resolve the warning and CFI failure.
- https://git.kernel.org/stable/c/04371a75a58422a301a9ff9ae3babd310ac3bb3f
- https://git.kernel.org/stable/c/0ad811cc08a937d875cbad0149c1bab17f84ba05
- https://git.kernel.org/stable/c/511b48ee8e4aec2d03d2af06b363d9eb3230b017
- https://git.kernel.org/stable/c/6e3c4d3fa5d458d685561ecbaf8daa9dba14979e
- https://git.kernel.org/stable/c/8f9941dea3a70b73f2063f9dcc4aaae6af03c5ba
- https://git.kernel.org/stable/c/a075c21ee026f4a74f9fce5928ea3c8d18a8af13
- https://git.kernel.org/stable/c/b2c92b2a3801b09b709cbefd9a9e4944b72400bf
- https://git.kernel.org/stable/c/b4307c7d35e346b909edfdc1f280902150570bb6
- https://git.kernel.org/stable/c/e578b0906b6a81479cd5b5b6c848a7096addf5e9
Modified: 2025-12-02
CVE-2022-50262
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate BOOT record_size
When the NTFS BOOT record_size field < 0, it represents a
shift value. However, there is no sanity check on the shift result
and the sbi->record_bits calculation through blksize_bits() assumes
the size always > 256, which could lead to NPD while mounting a
malformed NTFS image.
[ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158
[ 318.675682] #PF: supervisor read access in kernel mode
[ 318.675869] #PF: error_code(0x0000) - not-present page
[ 318.676246] PGD 0 P4D 0
[ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5
[ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0
[ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180
[ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246
[ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080
[ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080
[ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000
[ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000
[ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0
[ 318.685623] Call Trace:
[ 318.686607]
Modified: 2025-12-02
CVE-2022-50264
In the Linux kernel, the following vulnerability has been resolved: clk: socfpga: Fix memory leak in socfpga_gate_init() Free @socfpga_clk and @ops on the error path to avoid memory leak issue.
- https://git.kernel.org/stable/c/0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b
- https://git.kernel.org/stable/c/3e8fd1d0fab4d5c9a50d225dddc207deac12f13a
- https://git.kernel.org/stable/c/6f2198914fb9aac286a6ff6cf09b23752141e04f
- https://git.kernel.org/stable/c/9de42116fc4540f6a1ceb51fd037b734ab7be12e
- https://git.kernel.org/stable/c/9f9bb9f5ba9fd501a90f255eb746b4cf2ceeaaae
- https://git.kernel.org/stable/c/bd72ab5e6fc1c4d3e6b84636141d26a41b977b03
Modified: 2025-12-03
CVE-2022-50265
In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_wait kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. syzbot reported: BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1: reserve_rx_kcm net/kcm/kcmsock.c:283 [inline] kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0: kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x01 -> 0x00 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
- https://git.kernel.org/stable/c/0c745b5141a45a076f1cb9772a399f7ebcb0948a
- https://git.kernel.org/stable/c/2733fb2ad5bfbe6538f2f93a21f2504e3dba9d6a
- https://git.kernel.org/stable/c/62086d1c4602e4f2ec07b975165afc2ed0ff1be9
- https://git.kernel.org/stable/c/663682cd3192dd4f3547b7890a4391c72441001d
- https://git.kernel.org/stable/c/9ae47f11493509cde707af8ecc7eee04c8b8e635
- https://git.kernel.org/stable/c/dbc3a0b917c4f75292b1c0819c188e40fd3c8924
- https://git.kernel.org/stable/c/e2a28807b1ceaa309164b92c38d73d12feea33df
- https://git.kernel.org/stable/c/f1f7122bb2ef056afc6f91ce4c35ab6df1207c8d
Modified: 2025-12-03
CVE-2022-50267
In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_pci: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, beside, runtime PM also needs be disabled.
Modified: 2025-12-03
CVE-2022-50268
In the Linux kernel, the following vulnerability has been resolved: mmc: moxart: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host().
- https://git.kernel.org/stable/c/0ca18d09c744fb030ae9bc5836c3e357e0237dea
- https://git.kernel.org/stable/c/40aa73c70e8a5706f9cbe01409a5e51cc0f1750e
- https://git.kernel.org/stable/c/7c3b301ca8b0cab392c71da8fcdfa499074f8e97
- https://git.kernel.org/stable/c/8f8bb62c7c5c833758ef1563fe738afd579c3efe
- https://git.kernel.org/stable/c/a4c765f5d8e58138cff69f1510b2e8942ec37022
- https://git.kernel.org/stable/c/a94d466f31a5201995d39bc1208e2c09ab04f0bf
- https://git.kernel.org/stable/c/b174f2b36c638fc7737df6c8aac1889a646be98f
- https://git.kernel.org/stable/c/c7e9a2059fb943fc3c3fa12261518fd72a0fc136
- https://git.kernel.org/stable/c/f0502fe86a2db2336c9498d2de3e97f22dcf85ae
Modified: 2025-12-03
CVE-2022-50271
In the Linux kernel, the following vulnerability has been resolved:
vhost/vsock: Use kvmalloc/kvfree for larger packets.
When copying a large file over sftp over vsock, data size is usually 32kB,
and kmalloc seems to fail to try to allocate 32 32kB regions.
vhost-5837: page allocation failure: order:4, mode:0x24040c0
Call Trace:
[
- https://git.kernel.org/stable/c/0d720c3f0a03e97867deab7e480ba3d3e19837ba
- https://git.kernel.org/stable/c/0e3f72931fc47bb81686020cc643cde5d9cd0bb8
- https://git.kernel.org/stable/c/36c9f340c60413e28f980c0224c4e9d35851526b
- https://git.kernel.org/stable/c/7aac8c63f604e6a6a46560c0f0188cd0332cf320
- https://git.kernel.org/stable/c/a99fc6d818161d6f1ff3307de8bf5237f6cc34d8
- https://git.kernel.org/stable/c/b4a5905fd2ef841cd61e969ea692c213c2e5c1f7
- https://git.kernel.org/stable/c/e28a4e7f0296824c61a81e7fd54ab48bad3e75ad
- https://git.kernel.org/stable/c/e6d0152c95108651f1880c1ddfab47cb9e3e62d0
Modified: 2025-12-03
CVE-2022-50272
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()
Wei Chen reports a kernel bug as blew:
general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
...
Call Trace:
- https://git.kernel.org/stable/c/0ed554fd769a19ea8464bb83e9ac201002ef74ad
- https://git.kernel.org/stable/c/210fcf64be4db82c0e190e74b5111e4eef661a7a
- https://git.kernel.org/stable/c/2b6a8a1a32746981044e7ab06649c804acb4068a
- https://git.kernel.org/stable/c/559891d430e3f3a178040c4371ed419edbfa7d65
- https://git.kernel.org/stable/c/6b60cf73a931af34b7a0a3f467a79d9fe0df2d70
- https://git.kernel.org/stable/c/6fbc44731a4665cbe92a5090e9804a388a72214b
- https://git.kernel.org/stable/c/7abfe467cd685f5da7ecb415441e45e3e4e2baa8
- https://git.kernel.org/stable/c/8b256d23361c51aa4b7fdb71176c1ca50966fb39
- https://git.kernel.org/stable/c/c712d1ccbfb787620422b437a5b8fac0802547bd
Modified: 2025-12-03
CVE-2022-50273
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on destination blkaddr during recovery
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=216456
loop5: detected capacity change from 0 to 131072
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): Bitmap was wrongly set, blk:5634
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198
RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]
Call Trace:
- https://git.kernel.org/stable/c/0ef4ca04a3f9223ff8bc440041c524b2123e09a3
- https://git.kernel.org/stable/c/3a4d24d746866dd45d970bd565ff3886e839366a
- https://git.kernel.org/stable/c/68b1e607559d3dc85f94b0d738d7c4e8029b0cfa
- https://git.kernel.org/stable/c/73fb4bd2c055a393816f078f158cdd3025006f1d
- https://git.kernel.org/stable/c/8f0a47def4722c5fd8d6b9268b5ffed8a249e2db
- https://git.kernel.org/stable/c/ed854f10e6afd5cbd5c3274d4c4df4bfe0ab4362
Modified: 2025-12-03
CVE-2022-50274
In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: adopts refcnt to avoid UAF dvb_unregister_device() is known that prone to use-after-free. That is, the cleanup from dvb_unregister_device() releases the dvb_device even if there are pointers stored in file->private_data still refer to it. This patch adds a reference counter into struct dvb_device and delays its deallocation until no pointer refers to the object.
- https://git.kernel.org/stable/c/0fc044b2b5e2d05a1fa1fb0d7f270367a7855d79
- https://git.kernel.org/stable/c/219b44bf94203bd433aa91b7796475bf656348e5
- https://git.kernel.org/stable/c/2abd73433872194bccdf1432a0980e4ec5273c2a
- https://git.kernel.org/stable/c/6d18b44bb44e1f4d97dfe0efe92ac0f0984739c2
- https://git.kernel.org/stable/c/88a6f8a72d167294c0931c7874941bf37a41b6dd
- https://git.kernel.org/stable/c/9945d05d6693710574f354c5dbddc47f5101eb77
- https://git.kernel.org/stable/c/a2f0a08aa613176c9688c81d7b598a7779974991
- https://git.kernel.org/stable/c/ac521bbe3d00fa574e66a9361763f2b37725bc97
Modified: 2025-12-03
CVE-2022-50275
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Add the missed acpi_put_table() to fix memory leak When the radeon driver reads the bios information from ACPI table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table() to release the ACPI memory after the init, so add acpi_put_table() properly to fix the memory leak. v2: fix text formatting (Alex)
- https://git.kernel.org/stable/c/10276a20be1115e1f76c189330da2992df980eee
- https://git.kernel.org/stable/c/4539e3211a9bd2418e76797718a4e60a7ae34fcf
- https://git.kernel.org/stable/c/4760fa67aff6bd8ef0b14c1fa04c295e734c7309
- https://git.kernel.org/stable/c/50113de0f1e913c0b733e21d3e61fe9c0f2e9d50
- https://git.kernel.org/stable/c/6d25bc63708145c10f9c099d5c005602a7f2ef5f
- https://git.kernel.org/stable/c/9e203e437310f61fdf3c1107f41f85864cf4f6b1
- https://git.kernel.org/stable/c/a0f26560be2c566b62331cb0eeffa52929aa4d44
- https://git.kernel.org/stable/c/b4b30f56ec512e2c35fc0761bc90b0e519d8fa6e
Modified: 2025-12-03
CVE-2022-50276
In the Linux kernel, the following vulnerability has been resolved: power: supply: fix null pointer dereferencing in power_supply_get_battery_info when kmalloc() fail to allocate memory in kasprintf(), propname will be NULL, strcmp() called by of_get_property() will cause null pointer dereference. So return ENOMEM if kasprintf() return NULL pointer.
- https://git.kernel.org/stable/c/104bb8a663451404a26331263ce5b96c34504049
- https://git.kernel.org/stable/c/279af90e65cbdb3e5c4519b0043324d7876bc5ec
- https://git.kernel.org/stable/c/5beadb55f4e36fafe5d6df5dcd5f85d803f3f134
- https://git.kernel.org/stable/c/8ea68b4e3fa9392ef9dae303abc8735a033c280f
- https://git.kernel.org/stable/c/b8131efb89d9f837c9244f900f0fc2699fd1181d
- https://git.kernel.org/stable/c/d21534ab4fd7883e1c8037a76671d4e8b6ea14cb
Modified: 2025-12-03
CVE-2022-50278
In the Linux kernel, the following vulnerability has been resolved: PNP: fix name memory leak in pnp_alloc_dev() After commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, move dev_set_name() after pnp_add_id() to avoid memory leak.
- https://git.kernel.org/stable/c/110d7b0325c55ff3620073ba4201845f59e22ebf
- https://git.kernel.org/stable/c/1f50c7497a5f89de0c31f2edf086af41ff834320
- https://git.kernel.org/stable/c/290dd73b943c95c006df973257076ff163adf4d0
- https://git.kernel.org/stable/c/693a0c13c1f0c0fcaa1e38cb806cc0789bd415aa
- https://git.kernel.org/stable/c/81b024df4755e6bb6993b786584eca6eabbb9791
- https://git.kernel.org/stable/c/bbcf772216aa237036cc3ae3158288d0a95aaf4d
- https://git.kernel.org/stable/c/c12b314bb23dc0c83e03402cc84574700947e3b2
- https://git.kernel.org/stable/c/dac87e295cddc8ab316cff14ab2071b5221d84fa
- https://git.kernel.org/stable/c/ea77b4b761cd75e5456f677311babfa0418f289a
Modified: 2025-12-04
CVE-2022-50280
In the Linux kernel, the following vulnerability has been resolved: pnode: terminate at peers of source The propagate_mnt() function handles mount propagation when creating mounts and propagates the source mount tree @source_mnt to all applicable nodes of the destination propagation mount tree headed by @dest_mnt. Unfortunately it contains a bug where it fails to terminate at peers of @source_mnt when looking up copies of the source mount that become masters for copies of the source mount tree mounted on top of slaves in the destination propagation tree causing a NULL dereference. Once the mechanics of the bug are understood it's easy to trigger. Because of unprivileged user namespaces it is available to unprivileged users. While fixing this bug we've gotten confused multiple times due to unclear terminology or missing concepts. So let's start this with some clarifications: * The terms "master" or "peer" denote a shared mount. A shared mount belongs to a peer group. * A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @shared_mnt->mnt_group_id. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @shared_mnt->mnt_share. * The terms "slave mount" or "dependent mount" denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @shared_mnt->mnt_slave_list. * The term "master mount" denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term "master mount" - or "master" for short - is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slave_mount->mnt_master. Different slaves may point to different masters in the same peer group. * Multiple peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mnt_slave_lists of all peers in a peer group have to be walked. * Slave mounts point to a peer in the closest peer group they receive propagation from via @slave_mnt->mnt_master (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave mount receives propagation from. * A shared-slave mount is a slave mount to a peer group pg1 while also a peer in another peer group pg2. IOW, a peer group may receive propagation from another peer group. If a peer group pg1 is a slave to another peer group pg2 then all peers in peer group pg1 point to the same peer in peer group pg2 via ->mnt_master. IOW, all peers in peer group pg1 appear on the same ->mnt_slave_list. IOW, they cannot be slaves to different peer groups. * A pure slave mount is a slave mount that is a slave to a peer group but is not a peer in another peer group. * A propagation group denotes the set of mounts consisting of a single peer group pg1 and all slave mounts and shared-slave mounts that point to a peer in that peer group via ->mnt_master. IOW, all slave mounts such that @slave_mnt->mnt_master->mnt_group_id is equal to @shared_mnt->mnt_group_id. The concept of a propagation group makes it easier to talk about a single propagation level in a propagation tree. For example, in propagate_mnt() the immediate peers of @dest_mnt and all slaves of @dest_mnt's peer group form a propagation group pr ---truncated---
- https://git.kernel.org/stable/c/11933cf1d91d57da9e5c53822a540bbdc2656c16
- https://git.kernel.org/stable/c/2dae4211b579ce98985876a73a78466e285238ff
- https://git.kernel.org/stable/c/784a4f995ee24460aa72e00b085612fad57ebce5
- https://git.kernel.org/stable/c/7f57df69de7f05302fad584eb8e3f34de39e0311
- https://git.kernel.org/stable/c/b591b2919d018ef91b4a9571edca94105bcad3df
- https://git.kernel.org/stable/c/c24cc476acd8bccb5af54849aac5e779d8223bf5
- https://git.kernel.org/stable/c/cad0d17fb2b0540180ab59e2cd48ad348cc1ee4c
- https://git.kernel.org/stable/c/cc997490be65da0af8c75a6244fc80bb66c53ce0
- https://git.kernel.org/stable/c/e7c9f10c44a8919cd8bbd51b228c84d0caf7d518
Modified: 2025-12-04
CVE-2022-50281
In the Linux kernel, the following vulnerability has been resolved: MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create() In error case in bridge_platform_create after calling platform_device_add()/platform_device_add_data()/ platform_device_add_resources(), release the failed 'pdev' or it will be leak, call platform_device_put() to fix this problem. Besides, 'pdev' is divided into 'pdev_wd' and 'pdev_bd', use platform_device_unregister() to release sgi_w1 resources when xtalk-bridge registration fails.
- https://git.kernel.org/stable/c/11bec9cba4de06b3c0e9e4041453c2caaa1cbec1
- https://git.kernel.org/stable/c/48025893b3e31b917ad654d28d23fff66681cac4
- https://git.kernel.org/stable/c/93296e7ab774230b7c36541dead10b6da39b650f
- https://git.kernel.org/stable/c/d7ac29e60d0ff71e9e414af595b8c92800f7fa90
- https://git.kernel.org/stable/c/da2aecef866b476438d02c662507a0e4e818da9d
Modified: 2025-12-04
CVE-2022-50282
In the Linux kernel, the following vulnerability has been resolved:
chardev: fix error handling in cdev_device_add()
While doing fault injection test, I got the following report:
------------[ cut here ]------------
kobject: '(null)' (0000000039956980): is not initialized, yet kobject_put() is being called.
WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0
CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:kobject_put+0x23d/0x4e0
Call Trace:
- https://git.kernel.org/stable/c/11fa7fefe3d8fac7da56bc9aa3dd5fb3081ca797
- https://git.kernel.org/stable/c/28dc61cc49c6e995121c6d86bef4b73df78dda80
- https://git.kernel.org/stable/c/34d17b39bceef25e4cf9805cd59250ae05d0a139
- https://git.kernel.org/stable/c/5d2146889fad4cb9e6c13e790d4cfd871486eca8
- https://git.kernel.org/stable/c/6acf8597c5b04f455ee0649e11e5f3bcd28f381e
- https://git.kernel.org/stable/c/85a5660491b507d33662b8e81c142e6041e642eb
- https://git.kernel.org/stable/c/b5de1eac71fec1af7723f1083d23a24789fd795c
- https://git.kernel.org/stable/c/c46db6088bccff5115674d583fef46ede80077a2
- https://git.kernel.org/stable/c/d85b5247a79355b8432bfd9ac871f96117f750d4
Modified: 2025-12-04
CVE-2022-50285
In the Linux kernel, the following vulnerability has been resolved: mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages The h->*_huge_pages counters are protected by the hugetlb_lock, but alloc_huge_page has a corner case where it can decrement the counter outside of the lock. This could lead to a corrupted value of h->resv_huge_pages, which we have observed on our systems. Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a potential race.
- https://git.kernel.org/stable/c/112a005d1ded04a4b41b6d01833cc0bda90625cc
- https://git.kernel.org/stable/c/11993652d0b49e27272db0a37aa828d8a3a4b92b
- https://git.kernel.org/stable/c/12df140f0bdfae5dcfc81800970dd7f6f632e00c
- https://git.kernel.org/stable/c/2b35432d324898ec41beb27031d2a1a864a4d40e
- https://git.kernel.org/stable/c/3e50a07b6a5fcd39df1534d3fdaca4292a65efe6
- https://git.kernel.org/stable/c/568e3812b1778b4c0c229649b59977d88f400ece
- https://git.kernel.org/stable/c/629c986e19fe9481227c7cdfd9a105bbc104d245
- https://git.kernel.org/stable/c/c828fab903725279aa9dc6ae3d44bb7e4778f92c
Modified: 2025-12-23
CVE-2022-50286
In the Linux kernel, the following vulnerability has been resolved: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline When converting files with inline data to extents, delayed allocations made on a file system created with both the bigalloc and inline options can result in invalid extent status cache content, incorrect reserved cluster counts, kernel memory leaks, and potential kernel panics. With bigalloc, the code that determines whether a block must be delayed allocated searches the extent tree to see if that block maps to a previously allocated cluster. If not, the block is delayed allocated, and otherwise, it isn't. However, if the inline option is also used, and if the file containing the block is marked as able to store data inline, there isn't a valid extent tree associated with the file. The current code in ext4_clu_mapped() calls ext4_find_extent() to search the non-existent tree for a previously allocated cluster anyway, which typically finds nothing, as desired. However, a side effect of the search can be to cache invalid content from the non-existent tree (garbage) in the extent status tree, including bogus entries in the pending reservation tree. To fix this, avoid searching the extent tree when allocating blocks for bigalloc + inline files that are being converted from inline to extent mapped.
- https://git.kernel.org/stable/c/131294c35ed6f777bd4e79d42af13b5c41bf2775
- https://git.kernel.org/stable/c/6f4200ec76a0d31200c308ec5a71c68df5417004
- https://git.kernel.org/stable/c/81b915181c630ee1cffa052e52874fe4e1ba91ac
- https://git.kernel.org/stable/c/9404839e0c9db5a517ea83c0ca3388b39d105fdf
- https://git.kernel.org/stable/c/c0c8edbc8abbe8f16d80a1d794d1ba2c12b6f193
- https://git.kernel.org/stable/c/d440d6427a5e3a877c1c259b8d2b216ddb65e185
- https://git.kernel.org/stable/c/f83391339d8493b9ff24167516aaa5a5e88d8f81
Modified: 2025-12-03
CVE-2022-50288
In the Linux kernel, the following vulnerability has been resolved: qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure adapter->dcb would get silently freed inside qlcnic_dcb_enable() in case qlcnic_dcb_attach() would return an error, which always happens under OOM conditions. This would lead to use-after-free because both of the existing callers invoke qlcnic_dcb_get_info() on the obtained pointer, which is potentially freed at that point. Propagate errors from qlcnic_dcb_enable(), and instead free the dcb pointer at callsite using qlcnic_dcb_free(). This also removes the now unused qlcnic_clear_dcb_ops() helper, which was a simple wrapper around kfree() also causing memory leaks for partially initialized dcb. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
- https://git.kernel.org/stable/c/13a7c8964afcd8ca43c0b6001ebb0127baa95362
- https://git.kernel.org/stable/c/36999236f0b12d5de21a6f40e93b570727b9ceb2
- https://git.kernel.org/stable/c/513787ff9a331b461115e8a145a983d650a84fcb
- https://git.kernel.org/stable/c/8df1dc04ce0e4c03b51a756749c250a9cb17d707
- https://git.kernel.org/stable/c/8f97eeb02a553cdc78c83a0596448a370e1518c4
- https://git.kernel.org/stable/c/95df720e64a6409d8152827a776c43f615e3321a
- https://git.kernel.org/stable/c/a2a694e6edbdb3efb34e1613a31fdcf6cf444a55
- https://git.kernel.org/stable/c/d12a7510293d3370b234b0b7c5eda33e58786768
Modified: 2025-12-03
CVE-2022-50289
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix memory leak in ocfs2_stack_glue_init() ocfs2_table_header should be free in ocfs2_stack_glue_init() if ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak. BUG: memory leak unreferenced object 0xffff88810eeb5800 (size 128): comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s) hex dump (first 32 bytes): c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@.............. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0 [<00000000c04f70f7>] 0xffffffffa0050037 [<000000001bd12912>] do_one_initcall+0xdb/0x480 [<0000000064f766c9>] do_init_module+0x1cf/0x680 [<000000002ba52db0>] load_module+0x6441/0x6f20 [<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0 [<00000000380c1f22>] do_syscall_64+0x3f/0x90 [<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
- https://git.kernel.org/stable/c/0000281f019111526f7abccc61f2746d2eb626ca
- https://git.kernel.org/stable/c/0b2128b70849f2728949babfc1c760096ef72f5d
- https://git.kernel.org/stable/c/13b6269dd022aaa69ca8d1df374ab327504121cf
- https://git.kernel.org/stable/c/61d68cf2ba79128c48d4b3fa4d10c34dc18ba572
- https://git.kernel.org/stable/c/6f6c13776cbee4b6a515f4cd3b859f046be4f6f9
- https://git.kernel.org/stable/c/7c8bf45cea9c8d6fb3e14d8cd5ae60e0372f39b7
- https://git.kernel.org/stable/c/802abe2bc654e87334e6a0ab6c1adc2b6d5f6394
- https://git.kernel.org/stable/c/b0822faebd79971617abd495beb2d6f5356b88bf
- https://git.kernel.org/stable/c/f5f2682d3a34dd8350bf63f232d885fd95f25b92
Modified: 2025-12-04
CVE-2022-50291
In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_psock kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. We do the same for kcm->rx_wait in the following patch. syzbot reported: BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1: unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313 kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0: kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffff88812971ce00 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
- https://git.kernel.org/stable/c/12a0eb340c9a22e0f8c00d2c0c1a60695ead926a
- https://git.kernel.org/stable/c/13dba69e18d04c8eec7596369f2a0596b0260275
- https://git.kernel.org/stable/c/15e4dabda11b0fa31d510a915d1a580f47dfc92e
- https://git.kernel.org/stable/c/1b8a5692ab25db4ef1c2cc8e5d21f7a65dc3d079
- https://git.kernel.org/stable/c/342d918cf9a45df9cf11bbe7162b851adefd178f
- https://git.kernel.org/stable/c/bf46af730e58d340f6f740bc69a07c5f6b85c655
- https://git.kernel.org/stable/c/c325f92d8d9b223d5842609ca067e898e9d34566
- https://git.kernel.org/stable/c/e94395e916b48a5b912a0a04570981b5b091acb0
Modified: 2025-12-04
CVE-2022-50293
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range If we get -ENOMEM while dropping file extent items in a given range, at btrfs_drop_extents(), due to failure to allocate memory when attempting to increment the reference count for an extent or drop the reference count, we handle it with a BUG_ON(). This is excessive, instead we can simply abort the transaction and return the error to the caller. In fact most callers of btrfs_drop_extents(), directly or indirectly, already abort the transaction if btrfs_drop_extents() returns any error. Also, we already have error paths at btrfs_drop_extents() that may return -ENOMEM and in those cases we abort the transaction, like for example anything that changes the b+tree may return -ENOMEM due to a failure to allocate a new extent buffer when COWing an existing extent buffer, such as a call to btrfs_duplicate_item() for example. So replace the BUG_ON() calls with proper logic to abort the transaction and return the error.
Modified: 2025-12-04
CVE-2022-50296
In the Linux kernel, the following vulnerability has been resolved: UM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
- https://git.kernel.org/stable/c/16c546e148fa6d14a019431436a6f7b4087dbccd
- https://git.kernel.org/stable/c/2e3863cc02c156b51b50592d43ffa6a13b680b0d
- https://git.kernel.org/stable/c/5177bdc38eaa1c1ca6302214ab06913540cd00a2
- https://git.kernel.org/stable/c/6a73e6edcbf3cdd82796dcdf0c0f5fe5d91021af
- https://git.kernel.org/stable/c/7efe61dc6aa45aab8a40e304fa2dae21e33b0db4
- https://git.kernel.org/stable/c/844748412be03a236dcf4a208b588162a275e189
- https://git.kernel.org/stable/c/8f96aa67c2ccbd7e41b8dc992b8d13cfe206d571
- https://git.kernel.org/stable/c/cd251d39b13485eb94ee65bb000d024e02c00e45
- https://git.kernel.org/stable/c/dbd964a733db015bbb9dff592c259c736398140f
Modified: 2025-12-04
CVE-2022-50297
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: verify the expected usb_endpoints are present The bug arises when a USB device claims to be an ATH9K but doesn't have the expected endpoints. (In this case there was an interrupt endpoint where the driver expected a bulk endpoint.) The kernel needs to be able to handle such devices without getting an internal error. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Modules linked in: CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events request_firmware_work_func RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Call Trace: ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline] ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019 ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline] ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242 request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097 process_one_work+0x9af/0x1600 kernel/workqueue.c:2279 worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425 kthread+0x3b4/0x4a0 kernel/kthread.c:313 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/0b7e6d681e00a96cde2b32a15ffa70e1be2e3209
- https://git.kernel.org/stable/c/16ef02bad239f11f322df8425d302be62f0443ce
- https://git.kernel.org/stable/c/1824ccabee5445347b83642e4087cc2eca070343
- https://git.kernel.org/stable/c/2d2eccf52ea0215c8d386b62af0b5fd4fc122bd5
- https://git.kernel.org/stable/c/932f0a5e829fb0b823f96d7fa9a0f4fc96660b77
- https://git.kernel.org/stable/c/c319196a0e34ed2e66d6f876f58d8d446335c2a7
- https://git.kernel.org/stable/c/ca57748593ddd8e46d033fbaeb9d01ec533a6bfe
- https://git.kernel.org/stable/c/d008a202a0528a058bac658e657c010ce8534f4a
- https://git.kernel.org/stable/c/d64436af0bc3c9e579be761d7684f228fb95f3bb
Modified: 2025-12-04
CVE-2022-50298
In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd: cleanup in probe error path Add proper error path in probe() to cleanup resources previously acquired/allocated to fix warnings visible during probe deferral: notifier callback qcom_slim_ngd_ssr_notify already registered WARNING: CPU: 6 PID: 70 at kernel/notifier.c:28 notifier_chain_register+0x5c/0x90 Modules linked in: CPU: 6 PID: 70 Comm: kworker/u16:1 Not tainted 6.0.0-rc3-next-20220830 #380 Call trace: notifier_chain_register+0x5c/0x90 srcu_notifier_chain_register+0x44/0x90 qcom_register_ssr_notifier+0x38/0x4c qcom_slim_ngd_ctrl_probe+0xd8/0x400 platform_probe+0x6c/0xe0 really_probe+0xbc/0x2d4 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0x12c __device_attach_driver+0xb8/0x120 bus_for_each_drv+0x78/0xd0 __device_attach+0xa8/0x1c0 device_initial_probe+0x18/0x24 bus_probe_device+0xa0/0xac deferred_probe_work_func+0x88/0xc0 process_one_work+0x1d4/0x320 worker_thread+0x2cc/0x44c kthread+0x110/0x114 ret_from_fork+0x10/0x20
Modified: 2025-12-04
CVE-2022-50299
In the Linux kernel, the following vulnerability has been resolved:
md: Replace snprintf with scnprintf
Current code produces a warning as shown below when total characters
in the constituent block device names plus the slashes exceeds 200.
snprintf() returns the number of characters generated from the given
input, which could cause the expression “200 – len” to wrap around
to a large positive number. Fix this by using scnprintf() instead,
which returns the actual number of characters written into the buffer.
[ 1513.267938] ------------[ cut here ]------------
[ 1513.267943] WARNING: CPU: 15 PID: 37247 at
- https://git.kernel.org/stable/c/1727fd5015d8f93474148f94e34cda5aa6ad4a43
- https://git.kernel.org/stable/c/3b0a2bd51f60418ecd67493586a2bb2174199de3
- https://git.kernel.org/stable/c/41ca95033a0c47cd6dace1f0a36a6eb5ebe799e6
- https://git.kernel.org/stable/c/5d8259c9d1915a50c60c7d6e9e7fb9b7da64a175
- https://git.kernel.org/stable/c/76694e9ce0b2238c0a5f3ba54f9361dd3770ec78
- https://git.kernel.org/stable/c/897b1450abe5a67c842a5d24173ce4449ccdfa94
- https://git.kernel.org/stable/c/97238b88583c27c9d3b4a0cedb45f816523f17c3
- https://git.kernel.org/stable/c/f95825c4e51cf9a653b0ef947ac78401fc9d3a40
Modified: 2025-12-04
CVE-2022-50300
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix extent map use-after-free when handling missing device in read_one_chunk Store the error code before freeing the extent_map. Though it's reference counted structure, in that function it's the first and last allocation so this would lead to a potential use-after-free. The error can happen eg. when chunk is stored on a missing device and the degraded mount option is missing. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721
Modified: 2025-12-04
CVE-2022-50301
In the Linux kernel, the following vulnerability has been resolved: iommu/omap: Fix buffer overflow in debugfs There are two issues here: 1) The "len" variable needs to be checked before the very first write. Otherwise if omap2_iommu_dump_ctx() with "bytes" less than 32 it is a buffer overflow. 2) The snprintf() function returns the number of bytes that *would* have been copied if there were enough space. But we want to know the number of bytes which were *actually* copied so use scnprintf() instead.
- https://git.kernel.org/stable/c/0c7043a5b5c3b35f5dc8875757f71e7f491d64d4
- https://git.kernel.org/stable/c/184233a5202786b20220acd2d04ddf909ef18f29
- https://git.kernel.org/stable/c/2fee0dbfaeaaa4bda04279ce772c4572b1429d04
- https://git.kernel.org/stable/c/4010a1afaae1c0fb9c2cac5de703bed29b1f1782
- https://git.kernel.org/stable/c/648472df221f2bbffb433b964bcb87baccc586d8
- https://git.kernel.org/stable/c/706e359cf046c142db290244c3f4938b20fbe805
- https://git.kernel.org/stable/c/9814cc350e0765ce69244bf55ae4c8b29facd27e
- https://git.kernel.org/stable/c/bd0438f534b2e31b12f0b39b355c5dc2bbdaf854
- https://git.kernel.org/stable/c/ec53b99b6b9da8b501f001595a6260c03b42d5b7
Modified: 2025-12-04
CVE-2022-50302
In the Linux kernel, the following vulnerability has been resolved: lockd: set other missing fields when unlocking files vfs_lock_file() expects the struct file_lock to be fully initialised by the caller. Re-exported NFSv3 has been seen to Oops if the fl_file field is NULL.
- https://git.kernel.org/stable/c/18ebd35b61b4693a0ddc270b6d4f18def232e770
- https://git.kernel.org/stable/c/31c93ee5f1e4dc278b562e20f3c3274ac34997f3
- https://git.kernel.org/stable/c/688575aef211b0986fc51010116f5888a99d76a2
- https://git.kernel.org/stable/c/95d42a8d3d4ae84a0bd3ee23e1fee240cdf0a9f0
- https://git.kernel.org/stable/c/d7aa9f7778316beb690f6e2763b6d672ad8b256f
Modified: 2025-12-04
CVE-2022-50306
In the Linux kernel, the following vulnerability has been resolved: ext4: fix potential out of bound read in ext4_fc_replay_scan() For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read.
Modified: 2025-12-04
CVE-2022-50307
In the Linux kernel, the following vulnerability has been resolved: s390/cio: fix out-of-bounds access on cio_ignore free The channel-subsystem-driver scans for newly available devices whenever device-IDs are removed from the cio_ignore list using a command such as: echo free >/proc/cio_ignore Since an I/O device scan might interfer with running I/Os, commit 172da89ed0ea ("s390/cio: avoid excessive path-verification requests") introduced an optimization to exclude online devices from the scan. The newly added check for online devices incorrectly assumes that an I/O-subchannel's drvdata points to a struct io_subchannel_private. For devices that are bound to a non-default I/O subchannel driver, such as the vfio_ccw driver, this results in an out-of-bounds read access during each scan. Fix this by changing the scan logic to rely on a driver-independent online indication. For this we can use struct subchannel->config.ena, which is the driver's requested subchannel-enabled state. Since I/Os can only be started on enabled subchannels, this matches the intent of the original optimization of not scanning devices where I/O might be running.
Modified: 2025-12-04
CVE-2022-50308
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Add checks for devm_kcalloc As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference.
- https://git.kernel.org/stable/c/1bf5ee979076ceb121ee51c95197d890b1cee7f4
- https://git.kernel.org/stable/c/4518d7cc38b7d1a7ce5a7878ca601c91e19fe47d
- https://git.kernel.org/stable/c/7830e2289eb4b74970b6cd1b6cc68dcd021c2281
- https://git.kernel.org/stable/c/b1e4f92dd0c1d3c162d7ca6c1196995565cca96d
- https://git.kernel.org/stable/c/f849c116d320e85d1e2c2804c0edb0be3953b62d
Modified: 2025-12-04
CVE-2022-50309
In the Linux kernel, the following vulnerability has been resolved: media: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1c78f19c3a0ea312a8178a6bfd8934eb93e9b10a
- https://git.kernel.org/stable/c/22b93530bbe6af9dce8e520bb6e978d1bda39d2b
- https://git.kernel.org/stable/c/2630cc88327a5557aa0d9cc63be95e3c6e0a55b3
- https://git.kernel.org/stable/c/2ea7caa9684687cf3adc1467cf4af3653a776192
- https://git.kernel.org/stable/c/3336210948b22c2db43e9df2ea403d251b4d24ab
- https://git.kernel.org/stable/c/3c38467c3255c428cdbd3cefaccca4662f302dc9
- https://git.kernel.org/stable/c/59b315353252abe7b8fdb8651ca31b8484ce287a
- https://git.kernel.org/stable/c/6e7b3b1e4e9f739800cd8010b75a9bee8d808cee
- https://git.kernel.org/stable/c/7b0efe7534071e0153708886355d80db69525d50
Modified: 2025-12-04
CVE-2022-50311
In the Linux kernel, the following vulnerability has been resolved: cxl: Fix refcount leak in cxl_calc_capp_routing of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function only calls of_node_put() in normal path, missing it in the error path. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1d09697ff22908ae487fc8c4fbde1811732be523
- https://git.kernel.org/stable/c/2d7b6580384e6d65419933ddc525bd176095da54
- https://git.kernel.org/stable/c/651e8bc9d0418c20a1989b7c078c64c2a6346fa3
- https://git.kernel.org/stable/c/6a310e8db5409676b4b3e6c1f54dff174e4fd04d
- https://git.kernel.org/stable/c/81c8bbf5b2b5f0c8030fff1716c00849cda8571a
- https://git.kernel.org/stable/c/c9bebc503881c1391f6c4f820134884adecf1519
- https://git.kernel.org/stable/c/ee870f72465015327ad96204b0e92450d04870cd
- https://git.kernel.org/stable/c/f2d60f6ba173cded65081cee690b67802395a479
Modified: 2025-12-04
CVE-2022-50312
In the Linux kernel, the following vulnerability has been resolved: drivers: serial: jsm: fix some leaks in probe This error path needs to unwind instead of just returning directly.
- https://git.kernel.org/stable/c/1d5859ef229e381f4db38dce8ed58e4bf862006b
- https://git.kernel.org/stable/c/3bf05c2650cf6b8d83bf0b0d808cc78c6ee7e84c
- https://git.kernel.org/stable/c/3ea1fd63fdf0e83b491c2a9f25b395aa0e4bf6e8
- https://git.kernel.org/stable/c/6066bd69ffba3a6abc7c0793ccba1da79b7d77e3
- https://git.kernel.org/stable/c/6be8e565a4a60530797a974d0a3d0e30656166a1
- https://git.kernel.org/stable/c/71ffe5111f0ffa2fd43c14fd176c6f05d4e82212
- https://git.kernel.org/stable/c/737594536dc3ce732976c0d84bb1dcc842065521
- https://git.kernel.org/stable/c/744c2d33a88b082d9d504520f0132b3d688547b2
- https://git.kernel.org/stable/c/ff9a5e50fb1910be33e62925bc7ee3bef474879e
Modified: 2025-12-04
CVE-2022-50313
In the Linux kernel, the following vulnerability has been resolved: erofs: fix order >= MAX_ORDER warning due to crafted negative i_size As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly. Let's fall back to the generic path to deal with such unusual i_size. [1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com
- https://git.kernel.org/stable/c/0ab621fcdff1a58ff4de51a8590fa92a0ecd34be
- https://git.kernel.org/stable/c/17a0cdbd7b0cf0fc0d7ca4187a67f8f1c18c291f
- https://git.kernel.org/stable/c/1dd73601a1cba37a0ed5f89a8662c90191df5873
- https://git.kernel.org/stable/c/6235fb899b25fd287d5e42635ff82196395708cc
- https://git.kernel.org/stable/c/acc2f40b980c61a9178b72cdedd150b829064997
- https://git.kernel.org/stable/c/b6c8330f5b0f22149957a2e4977fd0f01a9db7cd
Modified: 2025-12-04
CVE-2022-50314
In the Linux kernel, the following vulnerability has been resolved: nbd: Fix hung when signal interrupts nbd_start_device_ioctl() syzbot reported hung task [1]. The following program is a simplified version of the reproducer: int main(void) { int sv[2], fd; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 1; if ((fd = open("/dev/nbd0", 0)) < 0) return 1; if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0) return 1; if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0) return 1; if (ioctl(fd, NBD_DO_IT) < 0) return 1; return 0; } When signal interrupt nbd_start_device_ioctl() waiting the condition atomic_read(&config->recv_threads) == 0, the task can hung because it waits the completion of the inflight IOs. This patch fixes the issue by clearing queue, not just shutdown, when signal interrupt nbd_start_device_ioctl().
- https://git.kernel.org/stable/c/1de7c3cf48fc41cd95adb12bd1ea9033a917798a
- https://git.kernel.org/stable/c/3575949513ea3b387b30dac1e69468a923c86caf
- https://git.kernel.org/stable/c/35fb7d4a53d9e36d1b91161ea9870d9c6d57dccf
- https://git.kernel.org/stable/c/3ba3846cb3e2fb3c6fbf79e998472821b298419e
- https://git.kernel.org/stable/c/62006a72b05e0d38727eef5188700f2488be5e89
- https://git.kernel.org/stable/c/b2700f98b3f4dd19fb4315b70581e5caff89eb49
- https://git.kernel.org/stable/c/c0d73be0af8c1310713bc39a8d7a22e35084e14f
- https://git.kernel.org/stable/c/c7b4641bd2395c2f3cd3b0a0cbf292ed9d489398
Modified: 2025-12-04
CVE-2022-50315
In the Linux kernel, the following vulnerability has been resolved:
ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS
UBSAN complains about array-index-out-of-bounds:
[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41
[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'
[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu
[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010
[ 1.980718] kernel: Call Trace:
[ 1.980721] kernel:
- https://git.kernel.org/stable/c/1e41e693f458eef2d5728207dbd327cd3b16580a
- https://git.kernel.org/stable/c/303d0f761431d848dd8d7ff9fd9b8c101879cabe
- https://git.kernel.org/stable/c/383b7c50f5445ff8dbbf03080905648d6980c39d
- https://git.kernel.org/stable/c/67a00c299c5c143817c948fbc7de1a2fa1af38fb
- https://git.kernel.org/stable/c/8fbe13de1cc7cef2564be3cbf60400b33eee023b
- https://git.kernel.org/stable/c/d6314d5f68764550c84d732ce901ddd3ac6b415f
- https://git.kernel.org/stable/c/da2ea4a961d9f89ed248734e7032350c260dc3a3
- https://git.kernel.org/stable/c/f70bd4339cb68bc7e206af4c922bc0d249244403
Modified: 2025-12-04
CVE-2022-50317
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: megachips: Fix a null pointer dereference bug When removing the module we will get the following warning: [ 31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered [ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI [ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130 [ 31.921825] Call Trace: [ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw] [ 31.923139] i2c_device_remove+0x181/0x1f0 The two bridges (stdp2690, stdp4028) do not probe at the same time, so the driver does not call ge_b850v3_resgiter() when probing, causing the driver to try to remove the object that has not been initialized. Fix this by checking whether both the bridges are probed.
- https://git.kernel.org/stable/c/1daf69228e310938177119c4eadcd30fc75c81e0
- https://git.kernel.org/stable/c/1ff673333d46d2c1b053ebd0c1c7c7c79e36943e
- https://git.kernel.org/stable/c/21764467ab396d9f08921e0a5ffa1214244e1ad9
- https://git.kernel.org/stable/c/4610e7a4111fa3f3ce27c09d6d94008c55f1cd31
- https://git.kernel.org/stable/c/5bc20bafcd87ba0858ab772cefc7047cb51bc249
- https://git.kernel.org/stable/c/7371fad5cfe6eada6bb5523c895fd6074b15c2b9
- https://git.kernel.org/stable/c/877e92e9b1bdeb580b31a46061005936be902cd4
- https://git.kernel.org/stable/c/aaa512ad1e59f2edf8a9e4f2b167a44b24670679
Modified: 2025-12-04
CVE-2022-50318
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox() pci_get_device() will increase the reference count for the returned 'dev'. We need to call pci_dev_put() to decrease the reference count. Since 'dev' is only used in pci_read_config_dword(), let's add pci_dev_put() right after it.
- https://git.kernel.org/stable/c/1ff9dd6e7071a561f803135c1d684b13c7a7d01d
- https://git.kernel.org/stable/c/3485f197518061371568f842405159aa9e4df551
- https://git.kernel.org/stable/c/48f32b9a74e2ac8e854bb87bfefdbc745125a123
- https://git.kernel.org/stable/c/5a96c10a56037db006ba6769307a9731cf6073be
- https://git.kernel.org/stable/c/bd66877c0b3b42eed0ecee0bd2a2a505c1e54177
- https://git.kernel.org/stable/c/c0539d5d474ee6fa4ebc41f927a0f98f81244f25
- https://git.kernel.org/stable/c/e293263248f25c6b8aa1caf7c1103d40aa03311e
Modified: 2025-12-04
CVE-2022-50319
In the Linux kernel, the following vulnerability has been resolved: coresight: trbe: remove cpuhp instance node before remove cpuhp state cpuhp_state_add_instance() and cpuhp_state_remove_instance() should be used in pairs. Or there will lead to the warn on cpuhp_remove_multi_state() since the cpuhp_step list is not empty. The following is the error log with 'rmmod coresight-trbe': Error: Removing state 215 which has instances left. Call trace: __cpuhp_remove_state_cpuslocked+0x144/0x160 __cpuhp_remove_state+0xac/0x100 arm_trbe_device_remove+0x2c/0x60 [coresight_trbe] platform_remove+0x34/0x70 device_remove+0x54/0x90 device_release_driver_internal+0x1e4/0x250 driver_detach+0x5c/0xb0 bus_remove_driver+0x64/0xc0 driver_unregister+0x3c/0x70 platform_driver_unregister+0x20/0x30 arm_trbe_exit+0x1c/0x658 [coresight_trbe] __arm64_sys_delete_module+0x1ac/0x24c invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x1a0 do_el0_svc+0x38/0xd0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x19c/0x1a0 ---[ end trace 0000000000000000 ]---
Modified: 2025-12-04
CVE-2022-50320
In the Linux kernel, the following vulnerability has been resolved:
ACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys address
On a Packard Bell Dot SC (Intel Atom N2600 model) there is a FPDT table
which contains invalid physical addresses, with high bits set which fall
outside the range of the CPU-s supported physical address range.
Calling acpi_os_map_memory() on such an invalid phys address leads to
the below WARN_ON in ioremap triggering resulting in an oops/stacktrace.
Add code to verify the physical address before calling acpi_os_map_memory()
to fix / avoid the oops.
[ 1.226900] ioremap: invalid physical address 3001000000000000
[ 1.226949] ------------[ cut here ]------------
[ 1.226962] WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:200 __ioremap_caller.cold+0x43/0x5f
[ 1.226996] Modules linked in:
[ 1.227016] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc3+ #490
[ 1.227029] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 1.227038] RIP: 0010:__ioremap_caller.cold+0x43/0x5f
[ 1.227054] Code: 96 00 00 e9 f8 af 24 ff 89 c6 48 c7 c7 d8 0c 84 99 e8 6a 96 00 00 e9 76 af 24 ff 48 89 fe 48 c7 c7 a8 0c 84 99 e8 56 96 00 00 <0f> 0b e9 60 af 24 ff 48 8b 34 24 48 c7 c7 40 0d 84 99 e8 3f 96 00
[ 1.227067] RSP: 0000:ffffb18c40033d60 EFLAGS: 00010286
[ 1.227084] RAX: 0000000000000032 RBX: 3001000000000000 RCX: 0000000000000000
[ 1.227095] RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00000000ffffffff
[ 1.227105] RBP: 3001000000000000 R08: 0000000000000000 R09: ffffb18c40033c18
[ 1.227115] R10: 0000000000000003 R11: ffffffff99d62fe8 R12: 0000000000000008
[ 1.227124] R13: 0003001000000000 R14: 0000000000001000 R15: 3001000000000000
[ 1.227135] FS: 0000000000000000(0000) GS:ffff913a3c080000(0000) knlGS:0000000000000000
[ 1.227146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.227156] CR2: 0000000000000000 CR3: 0000000018c26000 CR4: 00000000000006e0
[ 1.227167] Call Trace:
[ 1.227176]
Modified: 2025-12-04
CVE-2022-50323
In the Linux kernel, the following vulnerability has been resolved: net: do not sense pfmemalloc status in skb_append_pagefrags() skb_append_pagefrags() is used by af_unix and udp sendpage() implementation so far. In commit 326140063946 ("tcp: TX zerocopy should not sense pfmemalloc status") we explained why we should not sense pfmemalloc status for pages owned by user space. We should also use skb_fill_page_desc_noacc() in skb_append_pagefrags() to avoid following KCSAN report: BUG: KCSAN: data-race in lru_add_fn / skb_append_pagefrags write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:323 [inline] lru_add_fn+0x327/0x410 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 lru_add_drain_cpu+0x73/0x250 mm/swap.c:669 lru_add_drain+0x21/0x60 mm/swap.c:773 free_pages_and_swap_cache+0x16/0x70 mm/swap_state.c:311 tlb_batch_pages_flush mm/mmu_gather.c:59 [inline] tlb_flush_mmu_free mm/mmu_gather.c:256 [inline] tlb_flush_mmu+0x5b2/0x640 mm/mmu_gather.c:263 tlb_finish_mmu+0x86/0x100 mm/mmu_gather.c:363 exit_mmap+0x190/0x4d0 mm/mmap.c:3098 __mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copy_process+0x19fc/0x2100 kernel/fork.c:2518 kernel_clone+0x166/0x550 kernel/fork.c:2671 __do_sys_clone kernel/fork.c:2812 [inline] __se_sys_clone kernel/fork.c:2796 [inline] __x64_sys_clone+0xc3/0xf0 kernel/fork.c:2796 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1817 [inline] __skb_fill_page_desc include/linux/skbuff.h:2432 [inline] skb_fill_page_desc include/linux/skbuff.h:2453 [inline] skb_append_pagefrags+0x210/0x600 net/core/skbuff.c:3974 unix_stream_sendpage+0x45e/0x990 net/unix/af_unix.c:2338 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xffffea00058fc188 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
Modified: 2025-12-03
CVE-2022-50324
In the Linux kernel, the following vulnerability has been resolved:
mtd: maps: pxa2xx-flash: fix memory leak in probe
Free 'info' upon remapping error to avoid a memory leak.
[
- https://git.kernel.org/stable/c/1d0c2b762dad2b8dd166e17c0e90b88b86a3284f
- https://git.kernel.org/stable/c/2399401feee27c639addc5b7e6ba519d3ca341bf
- https://git.kernel.org/stable/c/6fa9550ef3e13d7e9b2d4db6dd57292ccd072a90
- https://git.kernel.org/stable/c/932baf593eb63dff40e40d7674f076fb7932cd5b
- https://git.kernel.org/stable/c/a1b061cafdbcb1ff259731f30e2bdc1de64dcaba
- https://git.kernel.org/stable/c/cb3f35f44887a8486737fe88d58050f1df290758
- https://git.kernel.org/stable/c/cf9c4c25caad05c6b492cbba739a467511814279
- https://git.kernel.org/stable/c/e2324a0912ad26a0ea5baaf81aed0ca880804158
- https://git.kernel.org/stable/c/f35981083cb3fc1ba6427c1543152c5e3f59d104
Modified: 2025-12-04
CVE-2022-50328
In the Linux kernel, the following vulnerability has been resolved: jbd2: fix potential use-after-free in jbd2_fc_wait_bufs In 'jbd2_fc_wait_bufs' use 'bh' after put buffer head reference count which may lead to use-after-free. So judge buffer if uptodate before put buffer head reference count.
- https://git.kernel.org/stable/c/1d4d16daec2a6689b6d3fbfc7d2078643adc6619
- https://git.kernel.org/stable/c/243d1a5d505d0b0460c9af0ad56ed4a56ef0bebd
- https://git.kernel.org/stable/c/2e6d9f381c1ed844531a577783fc352de7a44c8a
- https://git.kernel.org/stable/c/d11d2ded293976a1a0d9d9471827a44dc9e3c63f
- https://git.kernel.org/stable/c/effd9b3c029ecdd853a11933dcf857f5a7ca8c3d
Modified: 2025-12-04
CVE-2022-50330
In the Linux kernel, the following vulnerability has been resolved: crypto: cavium - prevent integer overflow loading firmware The "code_length" value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly. The "ntohl(ucode->code_length) * 2" multiplication can have an integer overflow.
- https://git.kernel.org/stable/c/172c8a24fc8312cf6b88d3c88469653fdcb1c127
- https://git.kernel.org/stable/c/2526d6bf27d15054bb0778b2f7bc6625fd934905
- https://git.kernel.org/stable/c/371fa5129af53a79f6dddc90fe5bb0825cbe72a4
- https://git.kernel.org/stable/c/3a720eb89026c5241b8c4abb33370dc6fb565eee
- https://git.kernel.org/stable/c/584561e94260268abe1c83e00d9c205565cb7bc5
- https://git.kernel.org/stable/c/90e483e7f20c32287d2a9da967e122938f52737a
- https://git.kernel.org/stable/c/c4d4c2afd08dfb3cd1c880d1811ede2568e81a6d
- https://git.kernel.org/stable/c/e29fd7a6852376d2cfb95ad5d6d3eeff93f815e9
Modified: 2025-12-03
CVE-2022-50331
In the Linux kernel, the following vulnerability has been resolved: wwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff88810152ad20 (size 8): comm "modprobe", pid 252, jiffies 4294849206 (age 22.713s) hex dump (first 8 bytes): 68 77 73 69 6d 30 00 ff hwsim0.. backtrace: [<000000009c3504ed>] __kmalloc_node_track_caller+0x44/0x1b0 [<00000000c0228a5e>] kvasprintf+0xb5/0x140 [<00000000cff8c21f>] kvasprintf_const+0x55/0x180 [<0000000055a1e073>] kobject_set_name_vargs+0x56/0x150 [<000000000a80b139>] dev_set_name+0xab/0xe0
Modified: 2025-12-04
CVE-2022-50333
In the Linux kernel, the following vulnerability has been resolved: fs: jfs: fix shift-out-of-bounds in dbDiscardAG This should be applied to most URSAN bugs found recently by syzbot, by guarding the dbMount. As syzbot feeding rubbish into the bmap descriptor.
- https://git.kernel.org/stable/c/0183c8f46ab5bcd0740f41c87f5141c6ca2bf1bb
- https://git.kernel.org/stable/c/10b87da8fae79c7daf5eda6a9e4f1d31b85b4d92
- https://git.kernel.org/stable/c/25e70c6162f207828dd405b432d8f2a98dbf7082
- https://git.kernel.org/stable/c/3d340b684dcec5e34efc470227cd1c7d2df121ad
- https://git.kernel.org/stable/c/50163a115831ef4e6402db5a7ef487d1989d7249
- https://git.kernel.org/stable/c/624843f1bac448150f6859999c72c4841c14a2e3
- https://git.kernel.org/stable/c/911999b193735cd378517b6cd5fe585ee345d49c
- https://git.kernel.org/stable/c/ab5cd3d62c2493eca3337e7d0178cc7bd819ca64
- https://git.kernel.org/stable/c/f8d4d0bac603616e2fa4a3907e81ed13f8f3c380
Modified: 2025-12-04
CVE-2022-50334
In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param()
Syzkaller reports a null-ptr-deref bug as follows:
======================================================
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380
[...]
Call Trace:
- https://git.kernel.org/stable/c/26215b7ee923b9251f7bb12c4e5f09dc465d35f2
- https://git.kernel.org/stable/c/965e8f8ae0f642b5528f5a82b7bcaf15a659d5bd
- https://git.kernel.org/stable/c/9a8862820cbf1f18dca4f3b4c289d88561b3a384
- https://git.kernel.org/stable/c/dcd28191be9bbf307ba51a5b485773a55b0037c4
- https://git.kernel.org/stable/c/f2207145693ae5697a7b59e2add4b92f9e5b0e3c
- https://git.kernel.org/stable/c/fa71639873518e3587632ae58e25e4a96b57fa90
Modified: 2025-12-04
CVE-2022-50335
In the Linux kernel, the following vulnerability has been resolved: 9p: set req refcount to zero to avoid uninitialized usage When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110): p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client.c:1165 clone_fid fs/9p/fid.h:21 [inline] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [inline] v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 path_setxattr+0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [inline] __se_sys_setxattr fs/xattr.c:648 [inline] __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Below is a similar scenario, the scenario in the syzbot log looks more complicated than this one, but this patch can fix it. T21124 p9_read_work ======================== second trans ================================= p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == uninitialized */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* increments uninitalized refcount */ refcount_set(&req->refcount, 2); /* cb drops one ref */ p9_client_cb(req) /* reader thread drops its ref: request is incorrectly freed */ p9_req_put(req) /* use after free and ref underflow */ p9_req_put(req) To fix it, we can initialize the refcount to zero before add to idr.
Modified: 2025-12-04
CVE-2022-50336
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Add null pointer check to attr_load_runs_vcn
Some metadata files are handled before MFT. This adds a null pointer
check for some corner cases that could lead to NPD while reading these
metadata files for a malformed NTFS image.
[ 240.190827] BUG: kernel NULL pointer dereference, address: 0000000000000158
[ 240.191583] #PF: supervisor read access in kernel mode
[ 240.191956] #PF: error_code(0x0000) - not-present page
[ 240.192391] PGD 0 P4D 0
[ 240.192897] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
[ 240.193805] CPU: 0 PID: 242 Comm: mount Tainted: G B 5.19.0+ #17
[ 240.194477] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 240.195152] RIP: 0010:ni_find_attr+0xae/0x300
[ 240.195679] Code: c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 e2 d9f
[ 240.196642] RSP: 0018:ffff88800812f690 EFLAGS: 00000286
[ 240.197019] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a
[ 240.197523] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60
[ 240.197877] RBP: ffff88800812f738 R08: 0000000000000001 R09: fffffbfff11d2bed
[ 240.198292] R10: ffffffff88e95f67 R11: fffffbfff11d2bec R12: 0000000000000000
[ 240.198647] R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000000
[ 240.199410] FS: 00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000
[ 240.199895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 240.200314] CR2: 0000000000000158 CR3: 0000000004d32000 CR4: 00000000000006f0
[ 240.200839] Call Trace:
[ 240.201104]
Modified: 2025-12-04
CVE-2022-50337
In the Linux kernel, the following vulnerability has been resolved: ocxl: fix pci device refcount leak when calling get_function_0() get_function_0() calls pci_get_domain_bus_and_slot(), as comment says, it returns a pci device with refcount increment, so after using it, pci_dev_put() needs be called. Get the device reference when get_function_0() is not called, so pci_dev_put() can be called in the error path and callers unconditionally. And add comment above get_dvsec_vendor0() to tell callers to call pci_dev_put().
- https://git.kernel.org/stable/c/27158c72678b39ee01cc01de1aba6b51c71abe2f
- https://git.kernel.org/stable/c/37a13b274e4513c757e50c002ddcbf4bc89adbb2
- https://git.kernel.org/stable/c/40ff4c2335a98f0ee96b099bfd70b8e6644f321f
- https://git.kernel.org/stable/c/9a1b3148975b71fdc194e62612478346bbe618cd
- https://git.kernel.org/stable/c/a40e1b0a922a53fa925ea8b296e3de30a31ed028
Modified: 2026-01-14
CVE-2022-50340
In the Linux kernel, the following vulnerability has been resolved:
media: vimc: Fix wrong function called when vimc_init() fails
In vimc_init(), when platform_driver_register(&vimc_pdrv) fails,
platform_driver_unregister(&vimc_pdrv) is wrongly called rather than
platform_device_unregister(&vimc_pdev), which causes kernel warning:
Unexpected driver unregister!
WARNING: CPU: 1 PID: 14517 at drivers/base/driver.c:270 driver_unregister+0x8f/0xb0
RIP: 0010:driver_unregister+0x8f/0xb0
Call Trace:
- https://git.kernel.org/stable/c/14d85b600bb1f6f8ef61fa8fc1907e2e623d8350
- https://git.kernel.org/stable/c/681ac2902039d9b497b3ae18fdc204314979e61e
- https://git.kernel.org/stable/c/9c9ff35d68691aaea85b2e93763772e23930b3a3
- https://git.kernel.org/stable/c/f38df8984ef1b45ba23888d0e232cc21a95bd04b
- https://git.kernel.org/stable/c/f74d3f326d1d5b8951ce263c59a121ecfa65e7c0
Modified: 2026-01-14
CVE-2022-50341
In the Linux kernel, the following vulnerability has been resolved: cifs: fix oops during encryption When running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr : scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov... Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses.
- https://git.kernel.org/stable/c/a13e51760703f71c25d5fc1f4a62dfa4b0cc80e9
- https://git.kernel.org/stable/c/bf0543b93740916ee91956f9a63da6fc0d79daaa
- https://git.kernel.org/stable/c/e8d16a54842d609fd4a3ed2d81d4333d6329aa94
- https://git.kernel.org/stable/c/e8e2861cc3258dbe407d01ea8c59bb5a53132301
- https://git.kernel.org/stable/c/f7f291e14dde32a07b1f0aa06921d28f875a7b54
- https://git.kernel.org/stable/c/fe6ea044c4f05706cb71040055b1c70c6c8275e0
Modified: 2026-01-14
CVE-2022-50342
In the Linux kernel, the following vulnerability has been resolved: floppy: Fix memory leak in do_floppy_init() A memory leak was reported when floppy_alloc_disk() failed in do_floppy_init(). unreferenced object 0xffff888115ed25a0 (size 8): comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 8 bytes): 00 ac 67 5b 81 88 ff ff ..g[.... backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<00000000a87bfa9e>] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180 [<000000006f02e8b1>] blk_mq_alloc_tag_set+0x573/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff88810fc30540 (size 32): comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<000000006b91eab4>] blk_mq_alloc_tag_set+0x393/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 If the floppy_alloc_disk() failed, disks of current drive will not be set, thus the lastest allocated set->tag cannot be freed in the error handling path. A simple call graph shown as below: floppy_module_init() floppy_init() do_floppy_init() for (drive = 0; drive < N_DRIVE; drive++) blk_mq_alloc_tag_set() blk_mq_alloc_tag_set_tags() blk_mq_realloc_tag_set_tags() # set->tag allocated floppy_alloc_disk() blk_mq_alloc_disk() # error occurred, disks failed to allocated ->out_put_disk: for (drive = 0; drive < N_DRIVE; drive++) if (!disks[drive][0]) # the last disks is not set and loop break break; blk_mq_free_tag_set() # the latest allocated set->tag leaked Fix this problem by free the set->tag of current drive before jump to error handling path. [efremov: added stable list, changed title]
Modified: 2026-01-14
CVE-2022-50343
In the Linux kernel, the following vulnerability has been resolved: rapidio: fix possible name leaks when rio_add_device() fails Patch series "rapidio: fix three possible memory leaks". This patchset fixes three name leaks in error handling. - patch #1 fixes two name leaks while rio_add_device() fails. - patch #2 fixes a name leak while rio_register_mport() fails. This patch (of 2): If rio_add_device() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and the 'rdev' can be freed in rio_release_dev().
- https://git.kernel.org/stable/c/3b4676f274a6b5d001176f15d0542100bbf4b59a
- https://git.kernel.org/stable/c/440afd7fd9b164fdde6fc9da8c47d3d7f20dcce8
- https://git.kernel.org/stable/c/80fad2e53eaed2b3a2ff596575f65669e13ceda5
- https://git.kernel.org/stable/c/85fbf58b15c09d3a6a03098c1e42ebfe9002f39d
- https://git.kernel.org/stable/c/88fa351b20ca300693a206ccd3c4b0e0647944d8
- https://git.kernel.org/stable/c/c413f65011ff8caffabcde0e1c3ceede48a48d6f
- https://git.kernel.org/stable/c/c482cb0deb57924335103fe592c379a076d867f8
- https://git.kernel.org/stable/c/ec3f04f74f50d0b6bac04d795c93c2b852753a7a
- https://git.kernel.org/stable/c/f9574cd48679926e2a569e1957a5a1bcc8a719ac
Modified: 2026-01-14
CVE-2022-50344
In the Linux kernel, the following vulnerability has been resolved: ext4: fix null-ptr-deref in ext4_write_info I caught a null-ptr-deref bug as follows: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339 RIP: 0010:ext4_write_info+0x53/0x1b0 [...] Call Trace: dquot_writeback_dquots+0x341/0x9a0 ext4_sync_fs+0x19e/0x800 __sync_filesystem+0x83/0x100 sync_filesystem+0x89/0xf0 generic_shutdown_super+0x79/0x3e0 kill_block_super+0xa1/0x110 deactivate_locked_super+0xac/0x130 deactivate_super+0xb6/0xd0 cleanup_mnt+0x289/0x400 __cleanup_mnt+0x16/0x20 task_work_run+0x11c/0x1c0 exit_to_user_mode_prepare+0x203/0x210 syscall_exit_to_user_mode+0x5b/0x3a0 do_syscall_64+0x59/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ================================================================== Above issue may happen as follows: ------------------------------------- exit_to_user_mode_prepare task_work_run __cleanup_mnt cleanup_mnt deactivate_super deactivate_locked_super kill_block_super generic_shutdown_super shrink_dcache_for_umount dentry = sb->s_root sb->s_root = NULL <--- Here set NULL sync_filesystem __sync_filesystem sb->s_op->sync_fs > ext4_sync_fs dquot_writeback_dquots sb->dq_op->write_info > ext4_write_info ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2) d_inode(sb->s_root) s_root->d_inode <--- Null pointer dereference To solve this problem, we use ext4_journal_start_sb directly to avoid s_root being used.
- https://git.kernel.org/stable/c/3638aa1c7d87c0ca0aef23cf58cae2c48e7daca4
- https://git.kernel.org/stable/c/4a657319cfabd6199fd0b7b65bbebf6ded7a11c1
- https://git.kernel.org/stable/c/533c60a0b97cee5daab376933f486207e6680fb7
- https://git.kernel.org/stable/c/947264e00c46de19a016fd81218118c708fed2f3
- https://git.kernel.org/stable/c/bb420e8afc854d2a1caaa23a0c129839acfb7888
- https://git.kernel.org/stable/c/dc451578446afd03c0c21913993c08898a691435
- https://git.kernel.org/stable/c/f34ab95162763cd7352f46df169296eec28b688d
- https://git.kernel.org/stable/c/f4b5ff0b794aa94afac7269c494550ca2f66511b
- https://git.kernel.org/stable/c/f9c1f248607d5546075d3f731e7607d5571f2b60
Modified: 2026-01-14
CVE-2022-50346
In the Linux kernel, the following vulnerability has been resolved:
ext4: init quota for 'old.inode' in 'ext4_rename'
Syzbot found the following issue:
ext4_parse_param: s_want_extra_isize=128
ext4_inode_info_init: s_want_extra_isize=32
ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828
__ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128
__ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128
ext4_xattr_block_set: inode=ffff88823869a2c8
------------[ cut here ]------------
WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980
Modules linked in:
RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980
RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000
RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178
RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e
R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000
R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000
FS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/13271fbbe85d73a7c47058f56a52f2a7f00d6e39
- https://git.kernel.org/stable/c/135ba9146f4d38abed48a540ef8a8770ff0bd34f
- https://git.kernel.org/stable/c/33fd7031d634f3b46e59f61adfbb0ea9fe514fef
- https://git.kernel.org/stable/c/67f6d5a4043f3db0c6bb0e14a0d97a7be8bfb8b5
- https://git.kernel.org/stable/c/7dfb8259f66faafa68d23a261b284d2c2c67649b
- https://git.kernel.org/stable/c/84a2f2ed49d6a4d92b354219077434c57d334620
- https://git.kernel.org/stable/c/def7a39091e60e1c4a2f623629082a00092602be
- https://git.kernel.org/stable/c/f263e349bacc2f303526dcfa61c4bc50132418b1
- https://git.kernel.org/stable/c/fae381a3d79bb94aa2eb752170d47458d778b797
Modified: 2026-01-14
CVE-2022-50347
In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called.
- https://git.kernel.org/stable/c/1491667d5450778a265eddddd294219acfd648cb
- https://git.kernel.org/stable/c/7fa922c7a3dd623fd59f1af50e8896fd9ca7f654
- https://git.kernel.org/stable/c/89303ddbb502c3bc8edbf864f9f85500c8fe07e9
- https://git.kernel.org/stable/c/937112e991ed25d1727d878734adcbef3b900274
- https://git.kernel.org/stable/c/a522e26a20a43dcfbef9ee9f71ed803290e852b0
- https://git.kernel.org/stable/c/d7ad7278be401b09c9f9a9f522cf4c449c7fd489
- https://git.kernel.org/stable/c/df683201c7ffbd21a806a7cad657b661c5ebfb6f
- https://git.kernel.org/stable/c/e598c9683fe1cf97c2b11b800cc3cee072108220
- https://git.kernel.org/stable/c/fc38a5a10e9e5a75eb9189854abeb8405b214cc9
Modified: 2026-01-14
CVE-2022-50348
In the Linux kernel, the following vulnerability has been resolved: nfsd: Fix a memory leak in an error handling path If this memdup_user() call fails, the memory allocated in a previous call a few lines above should be freed. Otherwise it leaks.
- https://git.kernel.org/stable/c/733dd17158f96aaa25408dc39bbb2738fda9300e
- https://git.kernel.org/stable/c/acc393aecda05bf64ed13b732931462e07a1bf08
- https://git.kernel.org/stable/c/aed8816305575b38dcc77feb6f1bc1d0ed32f5b8
- https://git.kernel.org/stable/c/cc3bca2110ac85cd964da997ef83d84cab0d49fb
- https://git.kernel.org/stable/c/e060c4b9f33c1fca74df26d57a98e784295327e6
- https://git.kernel.org/stable/c/fd1ef88049de09bc70d60b549992524cfc0e66ff
Modified: 2026-01-14
CVE-2022-50349
In the Linux kernel, the following vulnerability has been resolved: misc: tifm: fix possible memory leak in tifm_7xx1_switch_media() If device_register() returns error in tifm_7xx1_switch_media(), name of kobject which is allocated in dev_set_name() called in device_add() is leaked. Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized.
- https://git.kernel.org/stable/c/1695b1adcc3a7d985cd22fa3b55761edf3fab50d
- https://git.kernel.org/stable/c/2bbb222a54ff501f77ce593d21b76b79c905045e
- https://git.kernel.org/stable/c/35abbc8406cc39e72d3ce85f6e869555afe50d54
- https://git.kernel.org/stable/c/57c857353d5020bdec8284d9c0fee447484fe5e0
- https://git.kernel.org/stable/c/848c45964ded537107e010aaf353aa30a0855387
- https://git.kernel.org/stable/c/d861b7d41b17942b337d4b87a70de7cd1dc44d4e
- https://git.kernel.org/stable/c/ee2715faf7e7153f5142ed09aacfa89a64d45dcb
- https://git.kernel.org/stable/c/ef843ee20576039126d34d6eb5f45d14c3e6ce18
- https://git.kernel.org/stable/c/fd2c930cf6a5b9176382c15f9acb1996e76e25ad
Modified: 2026-01-14
CVE-2022-50351
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix xid leak in cifs_create() If the cifs already shutdown, we should free the xid before return, otherwise, the xid will be leaked.
Modified: 2026-01-14
CVE-2022-50352
In the Linux kernel, the following vulnerability has been resolved: net: hns: fix possible memory leak in hnae_ae_register() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
- https://git.kernel.org/stable/c/02dc0db19d944b4a90941db505ecf1aaec714be4
- https://git.kernel.org/stable/c/2974f3b330ef25f5d34a4948d04290c2cd7802cf
- https://git.kernel.org/stable/c/3b78453cca046d3b03853f0d077ad3ad130db886
- https://git.kernel.org/stable/c/7ae1345f6ad715acbcdc9e1ac28153684fd498bb
- https://git.kernel.org/stable/c/91f8f5342bee726ed5692583d58f69e7cc9ae60e
- https://git.kernel.org/stable/c/a3c148955c22fe1d94d7a2096005679c1f22eddf
- https://git.kernel.org/stable/c/dfc0337c6dceb6449403b33ecb141f4a1458a1e9
- https://git.kernel.org/stable/c/ff2f5ec5d009844ec28f171123f9e58750cef4bf
Modified: 2026-01-14
CVE-2022-50353
In the Linux kernel, the following vulnerability has been resolved: mmc: wmt-sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, clk_disable_unprepare() also needs be called.
- https://git.kernel.org/stable/c/29276d56f6ed138db0f38cd31aedc0b725c8c76c
- https://git.kernel.org/stable/c/58c3a8d0f1abeb1ca5c2df948be58ad4f7bb6f67
- https://git.kernel.org/stable/c/70b0620afab3c69d95a7e2dd7ceff162a21c4009
- https://git.kernel.org/stable/c/9bedf64dda84b29151e41591d8ded9ff0e6d336a
- https://git.kernel.org/stable/c/b40ac3b696a9c84b36211ef0c3f5a422650c101b
- https://git.kernel.org/stable/c/c7a328cea791cc2769b6417943939420913b4a46
- https://git.kernel.org/stable/c/eb7a2d516d4fbd165c07877a20feccb047342b1f
- https://git.kernel.org/stable/c/ecd6f77af3478f5223aa4011642a891b7dc91228
Modified: 2026-01-14
CVE-2022-50355
In the Linux kernel, the following vulnerability has been resolved: staging: vt6655: fix some erroneous memory clean-up loops In some initialization functions of this driver, memory is allocated with 'i' acting as an index variable and increasing from 0. The commit in "Fixes" introduces some clean-up codes in case of allocation failure, which free memory in reverse order with 'i' decreasing to 0. However, there are some problems: - The case i=0 is left out. Thus memory is leaked. - In case memory allocation fails right from the start, the memory freeing loops will start with i=-1 and invalid memory locations will be accessed. One of these loops has been fixed in commit c8ff91535880 ("staging: vt6655: fix potential memory leak"). Fix the remaining erroneous loops.
- https://git.kernel.org/stable/c/2a2db520e3ca5aafba7c211abfd397666c9b5f9d
- https://git.kernel.org/stable/c/637672a71f5016a40b0a6c0f3c8ad25eacedc8c3
- https://git.kernel.org/stable/c/88b9cc60f26e8a05d1ddbddf91b09ca2915f20e0
- https://git.kernel.org/stable/c/95ac62e8545be2b0a8cae0beef7c682e2e470e48
- https://git.kernel.org/stable/c/a9e9806d1c315bc50dce05479a079b9a104474b8
- https://git.kernel.org/stable/c/ed11b73c963292e7b49c0f37025c58ed3b7921d6
- https://git.kernel.org/stable/c/f19e5b7df54590c831f350381963f25585c8f7d5
Modified: 2026-01-14
CVE-2022-50356
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sfb: fix null pointer access issue when sfb_init() fails
When the default qdisc is sfb, if the qdisc of dev_queue fails to be
inited during mqprio_init(), sfb_reset() is invoked to clear resources.
In this case, the q->qdisc is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
sfb_init()
tcf_block_get() --->failed, q->qdisc is NULL
...
qdisc_put()
...
sfb_reset()
qdisc_reset(q->qdisc) --->q->qdisc is NULL
ops = qdisc->ops
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: 0010:qdisc_reset+0x2b/0x6f0
Call Trace:
Modified: 2026-01-14
CVE-2022-50358
In the Linux kernel, the following vulnerability has been resolved: brcmfmac: return error when getting invalid max_flowrings from dongle When firmware hit trap at initialization, host will read abnormal max_flowrings number from dongle, and it will cause kernel panic when doing iowrite to initialize dongle ring. To detect this error at early stage, we directly return error when getting invalid max_flowrings(>256).
- https://git.kernel.org/stable/c/10c4b63d09a5b0ebf1b61af1dae7f25555cf58b6
- https://git.kernel.org/stable/c/200347eb3b2608cc8b54c13dd1d5e03809ba2eb2
- https://git.kernel.org/stable/c/2aca4f3734bd717e04943ddf340d49ab62299a00
- https://git.kernel.org/stable/c/2e8bb402b060a6c22160de3d72cee057698177c8
- https://git.kernel.org/stable/c/3cc9299036bdb647408e11e41de3eb1ff6d428cd
- https://git.kernel.org/stable/c/87f126b25fa8562196f0f4c0aa46a446026199bf
Modified: 2026-01-14
CVE-2022-50359
In the Linux kernel, the following vulnerability has been resolved: media: cx88: Fix a null-ptr-deref bug in buffer_prepare() When the driver calls cx88_risc_buffer() to prepare the buffer, the function call may fail, resulting in a empty buffer and null-ptr-deref later in buffer_queue(). The following log can reveal it: [ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500 [ 41.836311] Call Trace: [ 41.836945] __enqueue_in_driver+0x141/0x360 [ 41.837262] vb2_start_streaming+0x62/0x4a0 [ 41.838216] vb2_core_streamon+0x1da/0x2c0 [ 41.838516] __vb2_init_fileio+0x981/0xbc0 [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120 [ 41.840072] vb2_fop_read+0x20e/0x400 [ 41.840346] v4l2_read+0x215/0x290 [ 41.840603] vfs_read+0x162/0x4c0 Fix this by checking the return value of cx88_risc_buffer() [hverkuil: fix coding style issues]
- https://git.kernel.org/stable/c/10c99d1c46ea9cd940029e17bab11d021f315c21
- https://git.kernel.org/stable/c/2b064d91440b33fba5b452f2d1b31f13ae911d71
- https://git.kernel.org/stable/c/4befc7ffa18ef9a4b70d854465313a345a06862f
- https://git.kernel.org/stable/c/644d5a87ab1863eb606526ea743021752a17e9cb
- https://git.kernel.org/stable/c/6f21976095c1e92454ab030976f95f40d652351b
- https://git.kernel.org/stable/c/704838040f3bdb4aa07ff4f26505a666a3defcfe
- https://git.kernel.org/stable/c/9181af2dbf06e7f432e5dbe88d10b22343e851b9
- https://git.kernel.org/stable/c/c2257c8a501537afab276c306cb717b7260276e1
- https://git.kernel.org/stable/c/c76d04d2079a4b7369ce9a0e859c0f3f2250bcc1
Modified: 2026-01-14
CVE-2022-50362
In the Linux kernel, the following vulnerability has been resolved: dmaengine: hisilicon: Add multi-thread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [383493.327077] Unable to handle kernel paging request at virtual address dead000000000108 [383493.335103] Mem abort info: [383493.335103] ESR = 0x96000044 [383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits [383493.335107] SET = 0, FnV = 0 [383493.335108] EA = 0, S1PTW = 0 [383493.335109] FSC = 0x04: level 0 translation fault [383493.335110] Data abort info: [383493.335111] ISV = 0, ISS = 0x00000044 [383493.364739] CM = 0, WnR = 1 [383493.367793] [dead000000000108] address between user and kernel address ranges [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump: loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [383493.465331] pc : vchan_tx_submit+0x64/0xa0 [383493.469957] lr : vchan_tx_submit+0x34/0xa0 This occurs because the transmission timed out, and that's due to data race. Each thread rewrite channels's descriptor as soon as device_issue_pending is called. It leads to the situation that the driver thinks that it uses the right descriptor in interrupt handler while channels's descriptor has been changed by other thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. That's why timeout reports. With current fixes channels' descriptor changes it's value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. In case of channel's descriptor is busy, try to submit to HW again when a descriptor is completed. In this case, vc->desc_issued may be empty when hisi_dma_start_transfer is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing.
- https://git.kernel.org/stable/c/2cbb95883c990d0002a77e13d3278913ab26ad79
- https://git.kernel.org/stable/c/7cb9b20941e1fb20d22d0a2f460a3d4fa417274c
- https://git.kernel.org/stable/c/af12e209a9d559394d35875ba0e6c80407605888
- https://git.kernel.org/stable/c/d4a8ec5cc7ff5d442bd49a44f26d74b2021ba4c8
- https://git.kernel.org/stable/c/f4cee0b385cd0348e071d4d80c4c13cfe547c70d
Modified: 2026-01-14
CVE-2022-50364
In the Linux kernel, the following vulnerability has been resolved: i2c: mux: reg: check return value after calling platform_get_resource() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code.
- https://git.kernel.org/stable/c/2d47b79d2bd39cc6369eccf94a06568d84c906ae
- https://git.kernel.org/stable/c/61df25c41b8e0d2c988ccf17139f70075a2e1ba4
- https://git.kernel.org/stable/c/8212800943997fab61874550278d653cb378c60c
- https://git.kernel.org/stable/c/f5049b3ad9446203b916ee375f30fa217735f63a
- https://git.kernel.org/stable/c/f7a440c89b6d460154efeb058272760e41bdfea8
Modified: 2026-01-14
CVE-2022-50365
In the Linux kernel, the following vulnerability has been resolved: skbuff: Account for tail adjustment during pull operations Extending the tail can have some unexpected side effects if a program uses a helper like BPF_FUNC_skb_pull_data to read partial content beyond the head skb headlen when all the skbs in the gso frag_list are linear with no head_frag - kernel BUG at net/core/skbuff.c:4219! pc : skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60 Fix this by marking these skbs as GSO_DODGY so segmentation can handle the tail updates accordingly.
- https://git.kernel.org/stable/c/2d59f0ca153e9573ec4f140988c0ccca0eb4181b
- https://git.kernel.org/stable/c/2d7afdcbc9d32423f177ee12b7c93783aea338fb
- https://git.kernel.org/stable/c/331615d837f4979eb91a336a223a5c7f7886ecd5
- https://git.kernel.org/stable/c/668dc454bcbd1da73605201ff43f988c70848215
- https://git.kernel.org/stable/c/6ac417d71b80e74b002313fcd73f7e9008e8e457
- https://git.kernel.org/stable/c/821be5a5ab09a40ba09cb5ba354f18cf7996fea0
- https://git.kernel.org/stable/c/8fb773eed4909ef5dc1bbeb3629a337d3336df7e
- https://git.kernel.org/stable/c/946dd5dc4fcc4123cdfe3942b20012c4448cf89a
- https://git.kernel.org/stable/c/ff3743d00f41d803e6ab9334962b674f3b7fd0cb
Modified: 2026-01-14
CVE-2022-50366
In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue When value < time_unit, the parameter of ilog2() will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger shift-out-of-bounds: shift exponent 18446744073709551615 is too large for 32-bit type 'int' Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us
- https://git.kernel.org/stable/c/139bbbd01114433b80fe59f5e1330615aadf9752
- https://git.kernel.org/stable/c/1d94af37565e4d3c26b0d63428e093a37d5b4c32
- https://git.kernel.org/stable/c/2d93540014387d1c73b9ccc4d7895320df66d01b
- https://git.kernel.org/stable/c/3eb0ba70376f6ee40fa843fc9cee49269370b0b3
- https://git.kernel.org/stable/c/42f79dbb9514f726ff21df25f09cb0693b0b2445
- https://git.kernel.org/stable/c/49a6ffdaed60f0eb52c198fafebc05994e16e305
- https://git.kernel.org/stable/c/4ebba43384722adbd325baec3a12c572d94488eb
- https://git.kernel.org/stable/c/6216b685b8f48ab7b721a6fd5acbf526b41c13e8
- https://git.kernel.org/stable/c/708b9abe1b4a2f050a483db4b7edfc446b13df1f
Modified: 2026-01-14
CVE-2022-50368
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502668/
- https://git.kernel.org/stable/c/21c4679af01f1027cb559330c2e7d410089b2b36
- https://git.kernel.org/stable/c/2e786eb2f9cebb07e317226b60054df510b60c65
- https://git.kernel.org/stable/c/4e5587cddb334f7a5bb1c49ea8bbfc966fafe1b8
- https://git.kernel.org/stable/c/9f035d1fb30648fe70ee01627eb131c56d699b35
- https://git.kernel.org/stable/c/e83b354890a3c1d5256162f87a6cc38c47ae7f20
- https://git.kernel.org/stable/c/f649ed0e1b7a1545f8e27267d3c468b3cb222ece
Modified: 2026-01-14
CVE-2022-50370
In the Linux kernel, the following vulnerability has been resolved: i2c: designware: Fix handling of real but unexpected device interrupts Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2c_dw_xfer_msg() when system resumes from S3 sleep state ("deep"). I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made following notes: - Issue happens when resuming from S3 but not when resuming from "s2idle" - PCI device 00:15.0 == i2c_designware.0 is already in D0 state when system enters into pci_pm_resume_noirq() while all other i2c_designware PCI devices are in D3. Devices were runtime suspended and in D3 prior entering into suspend - Interrupt comes after pci_pm_resume_noirq() when device interrupts are re-enabled - According to register dump the interrupt really comes from the i2c_designware.0. Controller is enabled, I2C target address register points to a one detectable I2C device address 0x60 and the DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and TX_EMPTY bits are set indicating completed I2C transaction. My guess is that the firmware uses this controller to communicate with an on-board I2C device during resume but does not disable the controller before giving control to an operating system. I was told the UEFI update fixes this but never the less it revealed the driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device is supposed to be idle and state variables are not set (especially the dev->msgs pointer which may point to NULL or stale old data). Introduce a new software status flag STATUS_ACTIVE indicating when the controller is active in driver point of view. Now treat all interrupts that occur when is not set as unexpected and mask all interrupts from the controller.
Modified: 2026-01-14
CVE-2022-50373
In the Linux kernel, the following vulnerability has been resolved:
fs: dlm: fix race in lowcomms
This patch fixes a race between queue_work() in
_dlm_lowcomms_commit_msg() and srcu_read_unlock(). The queue_work() can
take the final reference of a dlm_msg and so msg->idx can contain
garbage which is signaled by the following warning:
[ 676.237050] ------------[ cut here ]------------
[ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlm_lowcomms_commit_msg+0x41/0x50
[ 676.238945] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common iTCO_wdt iTCO_vendor_support qxl kvm_intel drm_ttm_helper vmw_vsock_virtio_transport kvm vmw_vsock_virtio_transport_common ttm irqbypass crc32_pclmul joydev crc32c_intel serio_raw drm_kms_helper vsock virtio_scsi virtio_console virtio_balloon snd_pcm drm syscopyarea sysfillrect sysimgblt snd_timer fb_sys_fops i2c_i801 lpc_ich snd i2c_smbus soundcore pcspkr
[ 676.244227] CPU: 0 PID: 1060 Comm: lock_torture_wr Not tainted 5.19.0-rc3+ #1546
[ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014
[ 676.246460] RIP: 0010:dlm_lowcomms_commit_msg+0x41/0x50
[ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48
[ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282
[ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006
[ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e
[ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001
[ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005
[ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480
[ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000
[ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0
[ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 676.258397] PKRU: 55555554
[ 676.258729] Call Trace:
[ 676.259063]
Modified: 2026-01-14
CVE-2022-50374
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure syzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1], for rcu_sync_enter() is called without rcu_sync_init() due to hci_uart_tty_open() ignoring percpu_init_rwsem() failure. While we are at it, fix that hci_uart_register_device() ignores percpu_init_rwsem() failure and hci_uart_unregister_device() does not call percpu_free_rwsem().
- https://git.kernel.org/stable/c/3124d320c22f3f4388d9ac5c8f37eaad0cefd6b1
- https://git.kernel.org/stable/c/75b2c71ea581c7bb1303860d89366a42ad0506d2
- https://git.kernel.org/stable/c/98ce10f3f345e61fc6c83bff9cd11cda252b05ac
- https://git.kernel.org/stable/c/b8917dce2134739b39bc0a5648b18427f2cad569
- https://git.kernel.org/stable/c/d7cc0d51ffcbfd1caaa809fcf9cff05c46d0fb4d
Modified: 2026-01-14
CVE-2022-50375
In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdown lpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can still occur which in turn tries to access dma apis if lpuart_dma_tx_use flag is true. At this point since dma is torn down, these dma apis can abort. Set lpuart_dma_tx_use and the corresponding rx flag lpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not accessed after they are relinquished. Otherwise, when try to kill btattach, kernel may panic. This patch may fix this issue. root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200 ^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP [ 90.189806] Modules linked in: moal(O) mlan(O) [ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37 [ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT) [ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60 [ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c [ 90.225237] sp : ffff800013f0bac0 [ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800 [ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00 [ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000 [ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000 [ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040 [ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090 [ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804 [ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480 [ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800 [ 90.299876] Call trace: [ 90.302321] fsl_edma3_disable_request+0x8/0x60 [ 90.306851] lpuart_flush_buffer+0x40/0x160 [ 90.311037] uart_flush_buffer+0x88/0x120 [ 90.315050] tty_driver_flush_buffer+0x20/0x30 [ 90.319496] hci_uart_flush+0x44/0x90 [ 90.323162] +0x34/0x12c [ 90.327253] tty_ldisc_close+0x38/0x70 [ 90.331005] tty_ldisc_release+0xa8/0x190 [ 90.335018] tty_release_struct+0x24/0x8c [ 90.339022] tty_release+0x3ec/0x4c0 [ 90.342593] __fput+0x70/0x234 [ 90.345652] ____fput+0x14/0x20 [ 90.348790] task_work_run+0x84/0x17c [ 90.352455] do_exit+0x310/0x96c [ 90.355688] do_group_exit+0x3c/0xa0 [ 90.359259] __arm64_sys_exit_group+0x1c/0x20 [ 90.363609] invoke_syscall+0x48/0x114 [ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc [ 90.372068] do_el0_svc+0x2c/0x94 [ 90.375379] el0_svc+0x28/0x80 [ 90.378438] el0t_64_sync_handler+0xa8/0x130 [ 90.382711] el0t_64_sync+0x1a0/0x1a4 [ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041) [ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]--- [ 90.397073] note: btattach[503] exited with preempt_count 1 [ 90.402636] Fixing recursive fault but reboot is needed!
- https://git.kernel.org/stable/c/29b897ac7b990882c74bd08605692214e7e58b83
- https://git.kernel.org/stable/c/316ae95c175a7d770d1bfe4c011192712f57aa4a
- https://git.kernel.org/stable/c/3953e7f261e2f4d9c35f0c025df9f166f46aa626
- https://git.kernel.org/stable/c/9a56ade124d4891a31ab1300c57665f07f5b24d5
- https://git.kernel.org/stable/c/c4293def8860fd587a84400ccba5b49cec56e2c3
- https://git.kernel.org/stable/c/d554c14eb73ee91d76fc9aece4616f0b687c295d
Modified: 2026-01-14
CVE-2022-50376
In the Linux kernel, the following vulnerability has been resolved: orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init() When insert and remove the orangefs module, there are memory leaked as below: unreferenced object 0xffff88816b0cc000 (size 2048): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): 6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f [<00000000e5a0085b>] 0xffffffffa02780f9 [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Use the golbal variable as the buffer rather than dynamic allocate to slove the problem.
- https://git.kernel.org/stable/c/0cd303aad220fafa595e0ed593e99aa51b90412b
- https://git.kernel.org/stable/c/31720a2b109b3080eb77e97b8f6f50a27b4ae599
- https://git.kernel.org/stable/c/786e5296f9e3b045d5ff9098514ce7b8ba1d890d
- https://git.kernel.org/stable/c/a076490b0211990ec6764328c22cb744dd782bd9
- https://git.kernel.org/stable/c/bdc2d33fa2324b1f5ab5b701cda45ee0b2384409
- https://git.kernel.org/stable/c/c8853267289c55b1acbe4dc3641374887584834d
Modified: 2026-01-14
CVE-2022-50378
In the Linux kernel, the following vulnerability has been resolved: drm/meson: reorder driver deinit sequence to fix use-after-free bug Unloading the driver triggers the following KASAN warning: [ +0.006275] ============================================================= [ +0.000029] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0 [ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695 [ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000007] dump_backtrace+0x1ec/0x280 [ +0.000013] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000010] __list_del_entry_valid+0xe0/0x1a0 [ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm] [ +0.000172] drm_bridge_detach+0x94/0x260 [drm] [ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm] [ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm] [ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm] [ +0.000144] drm_managed_release+0x170/0x414 [drm] [ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm] [ +0.000143] drm_dev_put+0x20/0x30 [drm] [ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm] [ +0.000028] take_down_aggregate_device+0xb0/0x160 [ +0.000016] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000015] platform_remove+0x64/0xb0 [ +0.000009] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000009] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000011] __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000018] Allocated by task 0: [ +0.000007] (stack is not available) [ +0.000011] Freed by task 2695: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000009] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000011] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [ +0.000008] component_unbind+0x128/0x1e0 [ +0.000010] component_unbind_all+0x1b8/0x264 [ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm] [ +0.000025] take_down_aggregate_device+0xb0/0x160 [ +0.000009] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000012] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000011] __do_sys_delete_module+0x288/0x400 [ +0.000010] __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] The buggy address belongs to the object at ffff000020c39000 ---truncated---
Modified: 2026-01-14
CVE-2022-50379
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between quota enable and quota rescan ioctl When enabling quotas, at btrfs_quota_enable(), after committing the transaction, we change fs_info->quota_root to point to the quota root we created and set BTRFS_FS_QUOTA_ENABLED at fs_info->flags. Then we try to start the qgroup rescan worker, first by initializing it with a call to qgroup_rescan_init() - however if that fails we end up freeing the quota root but we leave fs_info->quota_root still pointing to it, this can later result in a use-after-free somewhere else. We have previously set the flags BTRFS_FS_QUOTA_ENABLED and BTRFS_QGROUP_STATUS_FLAG_ON, so we can only fail with -EINPROGRESS at btrfs_quota_enable(), which is possible if someone already called the quota rescan ioctl, and therefore started the rescan worker. So fix this by ignoring an -EINPROGRESS and asserting we can't get any other error.
- https://git.kernel.org/stable/c/0efd9dfc00d677a1d0929319a6103cb2dfc41c22
- https://git.kernel.org/stable/c/26b7c0ac49a3eea15559c9d84863736a6d1164b4
- https://git.kernel.org/stable/c/331cd9461412e103d07595a10289de90004ac890
- https://git.kernel.org/stable/c/47b5ffe86332af95f0f52be0a63d4da7c2b37b55
- https://git.kernel.org/stable/c/4b996a3014ef014af8f97b60c35f5289210a4720
- https://git.kernel.org/stable/c/6c22f86dd221eba0c7af645b1af73dcbc04ee27b
- https://git.kernel.org/stable/c/c97f6d528c3f1c83a6b792a8a7928c236c80b8fe
Modified: 2026-01-14
CVE-2022-50380
In the Linux kernel, the following vulnerability has been resolved: mm: /proc/pid/smaps_rollup: fix no vma's null-deref Commit 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value seq_file") introduced a null-deref if there are no vma's in the task in show_smaps_rollup.
- https://git.kernel.org/stable/c/33fc9e26b7cb39f0d4219c875a2451802249c225
- https://git.kernel.org/stable/c/6bb8769326c46db3058780c0640dcc49d8187b24
- https://git.kernel.org/stable/c/97898139ca9b81ba9322a585e07490983c53b55a
- https://git.kernel.org/stable/c/a50ed2d28727ff605d95fb9a53be8ff94e8eaaf4
- https://git.kernel.org/stable/c/c4c84f06285e48f80e9843d0775ad92714ffc35a
- https://git.kernel.org/stable/c/dbe863bce7679c7f5ec0e993d834fe16c5e687b5
Modified: 2026-01-14
CVE-2022-50381
In the Linux kernel, the following vulnerability has been resolved:
md: fix a crash in mempool_free
There's a crash in mempool_free when running the lvm test
shell/lvchange-rebuild-raid.sh.
The reason for the crash is this:
* super_written calls atomic_dec_and_test(&mddev->pending_writes) and
wake_up(&mddev->sb_wait). Then it calls rdev_dec_pending(rdev, mddev)
and bio_put(bio).
* so, the process that waited on sb_wait and that is woken up is racing
with bio_put(bio).
* if the process wins the race, it calls bioset_exit before bio_put(bio)
is executed.
* bio_put(bio) attempts to free a bio into a destroyed bio set - causing
a crash in mempool_free.
We fix this bug by moving bio_put before atomic_dec_and_test.
We also move rdev_dec_pending before atomic_dec_and_test as suggested by
Neil Brown.
The function md_end_flush has a similar bug - we must call bio_put before
we decrement the number of in-progress bios.
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 11557f0067 P4D 11557f0067 PUD 0
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 73 Comm: kworker/0:1 Not tainted 6.1.0-rc3 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Workqueue: kdelayd flush_expired_bios [dm_delay]
RIP: 0010:mempool_free+0x47/0x80
Code: 48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 08 <48> 89 2c d0 e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00
RSP: 0018:ffff88910036bda8 EFLAGS: 00010093
RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8
RBP: ffff8891447ba240 R08: 0000000000012908 R09: 00000000003d0900
R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000
R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05
FS: 0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0
Call Trace:
- https://git.kernel.org/stable/c/341097ee53573e06ab9fc675d96a052385b851fa
- https://git.kernel.org/stable/c/384ef33d37cefb2ac539d44597d03f06c9b8975c
- https://git.kernel.org/stable/c/732cd66ec19a17f2b9183d7d5b7bdb9c39b0776e
- https://git.kernel.org/stable/c/842f222fc42a9239831e15b1fd49a51c546902cb
- https://git.kernel.org/stable/c/91bd504128a51776472445070e11a3b0f9348c90
- https://git.kernel.org/stable/c/97ce99984be12b9acb49ddce0f5d8ebb037adbb6
- https://git.kernel.org/stable/c/ae7793027766491c5f8635b12d15a5940d3b8698
- https://git.kernel.org/stable/c/b5be563b4356b3089b3245d024cae3f248ba7090
- https://git.kernel.org/stable/c/cf06b162f5b6337b688072a1a47941280b8f7110
Modified: 2026-01-14
CVE-2022-50382
In the Linux kernel, the following vulnerability has been resolved:
padata: Always leave BHs disabled when running ->parallel()
A deadlock can happen when an overloaded system runs ->parallel() in the
context of the current task:
padata_do_parallel
->parallel()
pcrypt_aead_enc/dec
padata_do_serial
spin_lock(&reorder->lock) // BHs still enabled
- https://git.kernel.org/stable/c/17afa98bccec4f52203508b3f49b5f948c6fd6ac
- https://git.kernel.org/stable/c/34c3a47d20ae55b3600fed733bf96eafe9c500d5
- https://git.kernel.org/stable/c/6cfa9e60c0f88fdec6368e081ab968411cc706b1
- https://git.kernel.org/stable/c/7337adb20fcc0aebb50eaff2bc5a8dd9a7c6743d
- https://git.kernel.org/stable/c/8e0681dd4eee029eb1d533d06993f7cb091efb73
Modified: 2026-01-14
CVE-2022-50384
In the Linux kernel, the following vulnerability has been resolved: staging: vme_user: Fix possible UAF in tsi148_dma_list_add Smatch report warning as follows: drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn: '&entry->list' not removed from list In tsi148_dma_list_add(), the error path "goto err_dma" will not remove entry->list from list->entries, but entry will be freed, then list traversal may cause UAF. Fix by removeing it from list->entries before free().
- https://git.kernel.org/stable/c/1f5661388f43df3ac106ce93e67d8d22b16a78ff
- https://git.kernel.org/stable/c/357057ee55d3c99a5de5abe8150f7bca04f8e53b
- https://git.kernel.org/stable/c/51c0ad3b7c5b01f9314758335a13f157b05fa56d
- https://git.kernel.org/stable/c/5cc4eea715a3fcf4e516662f736dfee63979465f
- https://git.kernel.org/stable/c/5d2b286eb034af114f67d9967fc3fbc1829bb712
- https://git.kernel.org/stable/c/85db68fc901da52314ded80aace99f8b684c7815
- https://git.kernel.org/stable/c/a45ba33d398a821147d7e5f16ead7eb125e331e2
- https://git.kernel.org/stable/c/cf138759a7e92c75cfc1b7ba705e4108fe330edf
- https://git.kernel.org/stable/c/e6b0adff99edf246ba1f8d464530a0438cb1cbda
Modified: 2026-01-14
CVE-2022-50385
In the Linux kernel, the following vulnerability has been resolved: NFS: Fix an Oops in nfs_d_automount() When mounting from a NFSv4 referral, path->dentry can end up being a negative dentry, so derive the struct nfs_server from the dentry itself instead.
- https://git.kernel.org/stable/c/35e3b6ae84935d0d7ff76cbdaa83411b0ad5e471
- https://git.kernel.org/stable/c/5458bc0f9df639d83471ca384152cc62dbee0aeb
- https://git.kernel.org/stable/c/6f3d56783fbed861e483736a7001bdafd0dddd53
- https://git.kernel.org/stable/c/b6fd25d64b0de27991d6bd677f0adf69ad6ff07a
- https://git.kernel.org/stable/c/f12377abac15fb4e8698225ac386894f8ae63598
Modified: 2026-01-14
CVE-2022-50386
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix user-after-free This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace: Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
- https://git.kernel.org/stable/c/0c108cf3ad386e0084277093b55a351c49e0be27
- https://git.kernel.org/stable/c/11e40d6c0823f699d8ad501e48d1c3ae4be386cd
- https://git.kernel.org/stable/c/15fc21695eb606bdc5d483b92118ee42610a952d
- https://git.kernel.org/stable/c/35fcbc4243aad7e7d020b7c1dfb14bb888b20a4f
- https://git.kernel.org/stable/c/6ffde6e03085874ae22263ff4cef4869f797e84f
- https://git.kernel.org/stable/c/7d6f9cb24d2b2f6b6370eac074e2e6b1bafdad45
- https://git.kernel.org/stable/c/843fc4e386dd84b806a7f07fb062d8c3a44e5364
- https://git.kernel.org/stable/c/d1e894f950ad48897d1a7cb05909ea29d8c3810e
- https://git.kernel.org/stable/c/d91fc2836562f299f34e361e089e9fe154da4f73
Modified: 2026-01-14
CVE-2022-50387
In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix the issue of CMDQ memory leaks When hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is not released correctly. Fix it.
Modified: 2026-01-14
CVE-2022-50388
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix multipath crash caused by flush request when blktrace is enabled
The flush request initialized by blk_kick_flush has NULL bio,
and it may be dealt with nvme_end_req during io completion.
When blktrace is enabled, nvme_trace_bio_complete with multipath
activated trying to access NULL pointer bio from flush request
results in the following crash:
[ 2517.831677] BUG: kernel NULL pointer dereference, address: 000000000000001a
[ 2517.835213] #PF: supervisor read access in kernel mode
[ 2517.838724] #PF: error_code(0x0000) - not-present page
[ 2517.842222] PGD 7b2d51067 P4D 0
[ 2517.845684] Oops: 0000 [#1] SMP NOPTI
[ 2517.849125] CPU: 2 PID: 732 Comm: kworker/2:1H Kdump: loaded Tainted: G S 5.15.67-0.cl9.x86_64 #1
[ 2517.852723] Hardware name: XFUSION 2288H V6/BC13MBSBC, BIOS 1.13 07/27/2022
[ 2517.856358] Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp]
[ 2517.859993] RIP: 0010:blk_add_trace_bio_complete+0x6/0x30
[ 2517.863628] Code: 1f 44 00 00 48 8b 46 08 31 c9 ba 04 00 10 00 48 8b 80 50 03 00 00 48 8b 78 50 e9 e5 fe ff ff 0f 1f 44 00 00 41 54 49 89 f4 55 <0f> b6 7a 1a 48 89 d5 e8 3e 1c 2b 00 48 89 ee 4c 89 e7 5d 89 c1 ba
[ 2517.871269] RSP: 0018:ff7f6a008d9dbcd0 EFLAGS: 00010286
[ 2517.875081] RAX: ff3d5b4be00b1d50 RBX: 0000000002040002 RCX: ff3d5b0a270f2000
[ 2517.878966] RDX: 0000000000000000 RSI: ff3d5b0b021fb9f8 RDI: 0000000000000000
[ 2517.882849] RBP: ff3d5b0b96a6fa00 R08: 0000000000000001 R09: 0000000000000000
[ 2517.886718] R10: 000000000000000c R11: 000000000000000c R12: ff3d5b0b021fb9f8
[ 2517.890575] R13: 0000000002000000 R14: ff3d5b0b021fb1b0 R15: 0000000000000018
[ 2517.894434] FS: 0000000000000000(0000) GS:ff3d5b42bfc80000(0000) knlGS:0000000000000000
[ 2517.898299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2517.902157] CR2: 000000000000001a CR3: 00000004f023e005 CR4: 0000000000771ee0
[ 2517.906053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2517.909930] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2517.913761] PKRU: 55555554
[ 2517.917558] Call Trace:
[ 2517.921294]
- https://git.kernel.org/stable/c/183c2aaef40a91acbaae45c3824d6cde7bb62b10
- https://git.kernel.org/stable/c/3659fb5ac29a5e6102bebe494ac789fd47fb78f4
- https://git.kernel.org/stable/c/4df413d46960f11c8c105238cfc3f5ff4c95c003
- https://git.kernel.org/stable/c/f13301a69ababa6c2236fb4f0393b7e914e7e1e0
- https://git.kernel.org/stable/c/fcd2d199486033223e9b2a6a7f9a01dd0327eac3
Modified: 2026-01-14
CVE-2022-50389
In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak In crb_acpi_add(), we get the TPM2 table to retrieve information like start method, and then assign them to the priv data, so the TPM2 table is not used after the init, should be freed, call acpi_put_table() to fix the memory leak.
- https://git.kernel.org/stable/c/08fd965521d0e172d540cf945517810895fcb199
- https://git.kernel.org/stable/c/0bd9b4be721c776f77adcaf34105dfca3007ddb9
- https://git.kernel.org/stable/c/1af2232b13837ce0f3a082b9f43735b09aafc367
- https://git.kernel.org/stable/c/2fcd3dc8b97a14f1672729c86b7041a1a89b052a
- https://git.kernel.org/stable/c/37e90c374dd11cf4919c51e847c6d6ced0abc555
- https://git.kernel.org/stable/c/927860dfa161ae8392a264197257dbdc52b26b0f
- https://git.kernel.org/stable/c/986cd9a9b95423e35a2cbb8e9105aec0e0d7f337
- https://git.kernel.org/stable/c/b0785edaf649e5f04dc7f75533e810f4c00e4106
Modified: 2026-01-14
CVE-2022-50392
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8183: fix refcount leak in mt8183_mt6358_ts3a227_max98357_dev_probe() The node returned by of_parse_phandle() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the error path in mt8183_mt6358_ts3a227_max98357_dev_probe().
Modified: 2026-01-14
CVE-2022-50394
In the Linux kernel, the following vulnerability has been resolved: i2c: ismt: Fix an out-of-bounds bug in ismt_access() When the driver does not check the data from the user, the variable 'data->block[0]' may be very large to cause an out-of-bounds bug. The following log can reveal it: [ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20 [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE [ 33.996475] ================================================================== [ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b [ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485 [ 33.999450] Call Trace: [ 34.001849] memcpy+0x20/0x60 [ 34.002077] ismt_access.cold+0x374/0x214b [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0 [ 34.004007] i2c_smbus_xfer+0x10a/0x390 [ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710 [ 34.005196] i2cdev_ioctl+0x5ec/0x74c Fix this bug by checking the size of 'data->block[0]' first.
- https://git.kernel.org/stable/c/03b7ef7a6c5ca1ff553470166b4919db88b810f6
- https://git.kernel.org/stable/c/233348a04becf133283f0076e20b317302de21d9
- https://git.kernel.org/stable/c/39244cc754829bf707dccd12e2ce37510f5b1f8d
- https://git.kernel.org/stable/c/4a7bb1d93addb2f67e36fed00a53cb7f270d7b7a
- https://git.kernel.org/stable/c/96c12fd0ec74641295e1c3c34dea3dce1b6c3422
- https://git.kernel.org/stable/c/9ac541a0898e8ec187a3fa7024b9701cffae6bf2
- https://git.kernel.org/stable/c/a642469d464b2780a25a49b51ae56623c65eac34
- https://git.kernel.org/stable/c/bfe41d966c860a8ad4c735639d616da270c92735
- https://git.kernel.org/stable/c/cdcbae2c5003747ddfd14e29db9c1d5d7e7c44dd
Modified: 2026-01-14
CVE-2022-50395
In the Linux kernel, the following vulnerability has been resolved: integrity: Fix memory leakage in keyring allocation error path Key restriction is allocated in integrity_init_keyring(). However, if keyring allocation failed, it is not freed, causing memory leaks.
- https://git.kernel.org/stable/c/29d6c69ba4b96a1de0376e44e5f8b38b13ec8803
- https://git.kernel.org/stable/c/39419ef7af0916cc3620ecf1ed42d29659109bf3
- https://git.kernel.org/stable/c/3bd737289c26be3cee4b9afaf61ef784a2af9d6e
- https://git.kernel.org/stable/c/57e49ad12f8f5df0c48e1710c54b147a05a10c32
- https://git.kernel.org/stable/c/9b7c44885a07c5ee7f9bf3aa3c9c72fb110c8d22
- https://git.kernel.org/stable/c/c591c48842f08d30ec6b8416757831985ed9a315
Modified: 2026-01-14
CVE-2022-50399
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: prevent integer overflow in sh_css_set_black_frame() The "height" and "width" values come from the user so the "height * width" multiplication can overflow.
Modified: 2026-01-14
CVE-2022-50400
In the Linux kernel, the following vulnerability has been resolved: staging: greybus: audio_helper: remove unused and wrong debugfs usage In the greybus audio_helper code, the debugfs file for the dapm has the potential to be removed and memory will be leaked. There is also the very real potential for this code to remove ALL debugfs entries from the system, and it seems like this is what will really happen if this code ever runs. This all is very wrong as the greybus audio driver did not create this debugfs file, the sound core did and controls the lifespan of it. So remove all of the debugfs logic from the audio_helper code as there's no way it could be correct. If this really is needed, it can come back with a fixup for the incorrect usage of the debugfs_lookup() call which is what caused this to be noticed at all.
- https://git.kernel.org/stable/c/4dab0d27a4211a27135a6899d6c737e6e0759a11
- https://git.kernel.org/stable/c/5699afbff1fa2972722e863906c0320d55dd4d58
- https://git.kernel.org/stable/c/d0febad83e29d85bb66e4f5cac0115b022403338
- https://git.kernel.org/stable/c/d517cdeb904ddc0cbebcc959d43596426cac40b0
- https://git.kernel.org/stable/c/d835fa49d9589a780ff0d001bb7e6323238a4afb
Modified: 2026-01-14
CVE-2022-50401
In the Linux kernel, the following vulnerability has been resolved:
nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure
On error situation `clp->cl_cb_conn.cb_xprt` should not be given
a reference to the xprt otherwise both client cleanup and the
error handling path of the caller call to put it. Better to
delay handing over the reference to a later branch.
[ 72.530665] refcount_t: underflow; use-after-free.
[ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120
[ 72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc]
[ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1
[ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014
[ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd]
[ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120
[ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48
[ 72.546666] RSP: 0018:ffffb3f841157cf0 EFLAGS: 00010286
[ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX: 0000000000000000
[ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0
[ 72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff
[ 72.550209] R10: 0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180
[ 72.551142] R13: ffff89ac6231d478 R14: ffff89ac40c06180 R15: ffff89ac6231d4b0
[ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000
[ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 72.553934] CR2: 0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0
[ 72.554874] Call Trace:
[ 72.555278]
- https://git.kernel.org/stable/c/15fc60aa5bdcf6d5f93000d3d00579fc67632ee0
- https://git.kernel.org/stable/c/3bc8edc98bd43540dbe648e4ef91f443d6d20a24
- https://git.kernel.org/stable/c/707bcca9616002d204091ca7c4d1d91151104332
- https://git.kernel.org/stable/c/9b4ae8c42d2ff09ed7c5832ccce5684c55e5ed23
- https://git.kernel.org/stable/c/a472f069ced8601979f53c13c0cf20236074ed46
- https://git.kernel.org/stable/c/c1207219a4bfa50121c9345d5d165470d0a82531
- https://git.kernel.org/stable/c/d843ebd860c58a38e45527e8ec6516059f4c97f3
- https://git.kernel.org/stable/c/e2f9f03e4537f3fcc8fd2bdd3248530c3477a371
- https://git.kernel.org/stable/c/fddac3b4578d302ac9e51e7f03a9aae6254ae2a3
Modified: 2026-01-14
CVE-2022-50402
In the Linux kernel, the following vulnerability has been resolved: drivers/md/md-bitmap: check the return value of md_bitmap_get_counter() Check the return value of md_bitmap_get_counter() in case it returns NULL pointer, which will result in a null pointer dereference. v2: update the check to include other dereference
- https://git.kernel.org/stable/c/100caacfa0ed26e061954c90cdc835d42f709536
- https://git.kernel.org/stable/c/21e9aac9a74d30907d44bae0d24c036cb3819406
- https://git.kernel.org/stable/c/3bd548e5b819b8c0f2c9085de775c5c7bff9052f
- https://git.kernel.org/stable/c/5d8d046f3dba939e74e2414f009df426700430ed
- https://git.kernel.org/stable/c/99bef41f8e8d1d52b5cb34f2f193f1346192752b
- https://git.kernel.org/stable/c/b621d17fe8b079574c773800148fb86907f3445d
- https://git.kernel.org/stable/c/ff3b7e12bc9f50de05c9d82b5b79e23e5be888f1
Modified: 2026-03-17
CVE-2022-50404
In the Linux kernel, the following vulnerability has been resolved: fbdev: fbcon: release buffer when fbcon_do_set_font() failed syzbot is reporting memory leak at fbcon_do_set_font() [1], for commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") missed that the buffer might be newly allocated by fbcon_set_font().
- https://git.kernel.org/stable/c/06926607b9fddf7ce8017493899ce6eb7e79a123
- https://git.kernel.org/stable/c/3c3bfb8586f848317ceba5d777e11204ba3e5758
- https://git.kernel.org/stable/c/5a341810a22e51c3a7a108f7896b5fd58d44d127
- https://git.kernel.org/stable/c/88ec6d11052da527eb9268831e7a9bc5bbad02f6
- https://git.kernel.org/stable/c/a609bfc1e644a8467cb31945ed1488374ebdc013
Modified: 2026-01-14
CVE-2022-50405
In the Linux kernel, the following vulnerability has been resolved: net/tunnel: wait until all sk_user_data reader finish before releasing the sock There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock.
- https://git.kernel.org/stable/c/303000c793f705d07b551eb7c1c27001c5b33c8d
- https://git.kernel.org/stable/c/3cf7203ca620682165706f70a1b12b5194607dce
- https://git.kernel.org/stable/c/588d0b8462f5ffed3e677e65639825b2678117ab
- https://git.kernel.org/stable/c/84e566d157cc22ad2da8bdd970495855fbf13d92
- https://git.kernel.org/stable/c/91f09a776ae335ca836ed864b8f2a9461882a280
- https://git.kernel.org/stable/c/9a6544343bba7da929d6d4a2dc44ec0f15970081
- https://git.kernel.org/stable/c/b38aa7465411795e9e744b8d94633910497fec2a
- https://git.kernel.org/stable/c/be34e79e0ae6adbf6e7e75ddaee9ad84795ab933
- https://git.kernel.org/stable/c/e8316584b0a6c61c9c407631040c22712b26e38c
Modified: 2026-01-14
CVE-2022-50408
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit() > ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb); may be schedule, and then complete before the line > ndev->stats.tx_bytes += skb->len; [ 46.912801] ================================================================== [ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328 [ 46.935991] [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1 [ 46.947255] Hardware name: [REDACTED] [ 46.954568] Call trace: [ 46.957037] dump_backtrace+0x0/0x2b8 [ 46.960719] show_stack+0x24/0x30 [ 46.964052] dump_stack+0x128/0x194 [ 46.967557] print_address_description.isra.0+0x64/0x380 [ 46.972877] __kasan_report+0x1d4/0x240 [ 46.976723] kasan_report+0xc/0x18 [ 46.980138] __asan_report_load4_noabort+0x18/0x20 [ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.990613] dev_hard_start_xmit+0x1bc/0xda0 [ 46.994894] sch_direct_xmit+0x198/0xd08 [ 46.998827] __qdisc_run+0x37c/0x1dc0 [ 47.002500] __dev_queue_xmit+0x1528/0x21f8 [ 47.006692] dev_queue_xmit+0x24/0x30 [ 47.010366] neigh_resolve_output+0x37c/0x678 [ 47.014734] ip_finish_output2+0x598/0x2458 [ 47.018927] __ip_finish_output+0x300/0x730 [ 47.023118] ip_output+0x2e0/0x430 [ 47.026530] ip_local_out+0x90/0x140 [ 47.030117] igmpv3_sendpack+0x14c/0x228 [ 47.034049] igmpv3_send_cr+0x384/0x6b8 [ 47.037895] igmp_ifc_timer_expire+0x4c/0x118 [ 47.042262] call_timer_fn+0x1cc/0xbe8 [ 47.046021] __run_timers+0x4d8/0xb28 [ 47.049693] run_timer_softirq+0x24/0x40 [ 47.053626] __do_softirq+0x2c0/0x117c [ 47.057387] irq_exit+0x2dc/0x388 [ 47.060715] __handle_domain_irq+0xb4/0x158 [ 47.064908] gic_handle_irq+0x58/0xb0 [ 47.068581] el0_irq_naked+0x50/0x5c [ 47.072162] [ 47.073665] Allocated by task 328: [ 47.077083] save_stack+0x24/0xb0 [ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0 [ 47.084776] kasan_slab_alloc+0x14/0x20 [ 47.088622] kmem_cache_alloc+0x15c/0x468 [ 47.092643] __alloc_skb+0xa4/0x498 [ 47.096142] igmpv3_newpack+0x158/0xd78 [ 47.099987] add_grhead+0x210/0x288 [ 47.103485] add_grec+0x6b0/0xb70 [ 47.106811] igmpv3_send_cr+0x2e0/0x6b8 [ 47.110657] igmp_ifc_timer_expire+0x4c/0x118 [ 47.115027] call_timer_fn+0x1cc/0xbe8 [ 47.118785] __run_timers+0x4d8/0xb28 [ 47.122457] run_timer_softirq+0x24/0x40 [ 47.126389] __do_softirq+0x2c0/0x117c [ 47.130142] [ 47.131643] Freed by task 180: [ 47.134712] save_stack+0x24/0xb0 [ 47.138041] __kasan_slab_free+0x108/0x180 [ 47.142146] kasan_slab_free+0x10/0x18 [ 47.145904] slab_free_freelist_hook+0xa4/0x1b0 [ 47.150444] kmem_cache_free+0x8c/0x528 [ 47.154292] kfree_skbmem+0x94/0x108 [ 47.157880] consume_skb+0x10c/0x5a8 [ 47.161466] __dev_kfree_skb_any+0x88/0xa0 [ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil] [ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac] [ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac] [ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac] [ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac] [ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac] [ 47.197859] process_one_work+0x7fc/0x1a80 [ 47.201965] worker_thread+0x31c/0xc40 [ 47.205726] kthread+0x2d8/0x370 [ 47.208967] ret_from_fork+0x10/0x18 [ 47.212546] [ 47.214051] The buggy address belongs to the object at ffffff803f588280 [ 47.214051] which belongs to the cache skbuff_head_cache of size 208 [ 47.227086] The buggy address is located 104 bytes inside of [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350) [ 47.238814] The buggy address belongs to the page: [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou ---truncated---
- https://git.kernel.org/stable/c/1613a7b24f1a7467cb727ba3ec77c9a808383560
- https://git.kernel.org/stable/c/232d59eca07f6ea27307022a33d226aff373bd02
- https://git.kernel.org/stable/c/27574a3f421c3a1694d0207f37c6bbf23d66978e
- https://git.kernel.org/stable/c/3f42faf6db431e04bf942d2ebe3ae88975723478
- https://git.kernel.org/stable/c/49c742afd60f552fce7799287080db02bffe1db2
- https://git.kernel.org/stable/c/c369836cff98d3877f98c98e15c0151462812d96
- https://git.kernel.org/stable/c/d79f4d903e14dde822c60b5fd3bedc5a289d25df
- https://git.kernel.org/stable/c/e01d96494a9de0f48b1167f0494f6d929fa773ed
Modified: 2025-12-23
CVE-2022-50409
In the Linux kernel, the following vulnerability has been resolved:
net: If sock is dead don't access sock's sk_wq in sk_stream_wait_memory
Fixes the below NULL pointer dereference:
[...]
[ 14.471200] Call Trace:
[ 14.471562]
- https://git.kernel.org/stable/c/124b7c773271f06af5a2cea694b283cdb5275cf5
- https://git.kernel.org/stable/c/35f5e70bdfa7432762ac4ffa75e5a7574ac5563e
- https://git.kernel.org/stable/c/3f8ef65af927db247418d4e1db49164d7a158fc5
- https://git.kernel.org/stable/c/435f5aa4421782af197b98d8525263977be4af5c
- https://git.kernel.org/stable/c/65029aaedd15d9fe5ea1a899134e236d83f627bb
- https://git.kernel.org/stable/c/a76462dbdd8bddcbeec9463bc9e54e509b860762
Modified: 2026-01-14
CVE-2022-50410
In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer overflow in NFSv2 READ Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case.
- https://git.kernel.org/stable/c/1868332032eccbab8c1878a0d918193058c0a905
- https://git.kernel.org/stable/c/2007867c5874134f2271eb276398208070049dd3
- https://git.kernel.org/stable/c/2be9331ca6061bc6ea32247266f45b8b21030244
- https://git.kernel.org/stable/c/401bc1f90874280a80b93f23be33a0e7e2d1f912
- https://git.kernel.org/stable/c/ea4c3eee0fd72fcedaa238556044825639cd3607
Modified: 2026-01-14
CVE-2022-50411
In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix error code path in acpi_ds_call_control_method() A use-after-free in acpi_ps_parse_aml() after a failing invocaion of acpi_ds_call_control_method() is reported by KASAN [1] and code inspection reveals that next_walk_state pushed to the thread by acpi_ds_create_walk_state() is freed on errors, but it is not popped from the thread beforehand. Thus acpi_ds_get_current_walk_state() called by acpi_ps_parse_aml() subsequently returns it as the new walk state which is incorrect. To address this, make acpi_ds_call_control_method() call acpi_ds_pop_walk_state() to pop next_walk_state from the thread before returning an error.
- https://git.kernel.org/stable/c/0462fec709d51762ba486245bc344f44cc6cfa97
- https://git.kernel.org/stable/c/2deb42c4f9776e59bee247c14af9c5e8c05ca9a6
- https://git.kernel.org/stable/c/38e251d356a01b61a86cb35213cafd7e8fe7090c
- https://git.kernel.org/stable/c/404ec60438add1afadaffaed34bb5fe4ddcadd40
- https://git.kernel.org/stable/c/5777432ebaaf797e24f059979b42df3139967163
- https://git.kernel.org/stable/c/799881db3e03b5e98fe6a900d9d7de8c7d61e7ee
- https://git.kernel.org/stable/c/9ef353c92f9d04c88de3af1a46859c1fb76db0f8
- https://git.kernel.org/stable/c/b0b83d3f3ffa96e8395c56b83d6197e184902a34
- https://git.kernel.org/stable/c/f520d181477ec29a496c0b3bbfbdb7e2606c2713
Modified: 2026-01-14
CVE-2022-50412
In the Linux kernel, the following vulnerability has been resolved: drm: bridge: adv7511: unregister cec i2c device after cec adapter cec_unregister_adapter() assumes that the underlying adapter ops are callable. For example, if the CEC adapter currently has a valid physical address, then the unregistration procedure will invalidate the physical address by setting it to f.f.f.f. Whence the following kernel oops observed after removing the adv7511 module: Unable to handle kernel execution of user memory at virtual address 0000000000000000 Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP Call trace: 0x0 adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511] cec_adap_unconfigure+0x44/0x90 [cec] __cec_s_phys_addr.part.0+0x68/0x230 [cec] __cec_s_phys_addr+0x40/0x50 [cec] cec_unregister_adapter+0xb4/0x118 [cec] adv7511_remove+0x60/0x90 [adv7511] i2c_device_remove+0x34/0xe0 device_release_driver_internal+0x114/0x1f0 driver_detach+0x54/0xe0 bus_remove_driver+0x60/0xd8 driver_unregister+0x34/0x60 i2c_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511] __arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100 el0_svc_common.constprop.0+0x48/0xe8 do_el0_svc+0x28/0x88 el0_svc+0x1c/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x15c/0x160 Code: bad PC value ---[ end trace 0000000000000000 ]--- Protect against this scenario by unregistering i2c_cec after unregistering the CEC adapter. Duly disable the CEC clock afterwards too.
- https://git.kernel.org/stable/c/3747465c5da7a11957a34bbb9485d9fc253b91cc
- https://git.kernel.org/stable/c/40cdb02cb9f965732eb543d47f15bef8d10f0f5f
- https://git.kernel.org/stable/c/4d4d5bc659206b187263190ad9a03513f625659d
- https://git.kernel.org/stable/c/86ae5170786aea3e1751123ca55700fb9b37b623
- https://git.kernel.org/stable/c/f369fb4deed7ab997cfa703dc85ec08b3adc1af8
Modified: 2026-01-14
CVE-2022-50414
In the Linux kernel, the following vulnerability has been resolved:
scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails
fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when
fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed
&fcoe_sw_transport on fcoe_transports list. This causes panic when
reinserting module.
BUG: unable to handle page fault for address: fffffbfff82e2213
RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe]
Call Trace:
- https://git.kernel.org/stable/c/09a60f908d8b6497f618113b7c3c31267dc90911
- https://git.kernel.org/stable/c/1dc499c615aa87dc46a3f2d1f91d2d358e55f3e3
- https://git.kernel.org/stable/c/22e8c7a56bb1cd2ed0beaaccb34282ac9cbbe27e
- https://git.kernel.org/stable/c/4155658cee394b22b24c6d64e49247bf26d95b92
- https://git.kernel.org/stable/c/aef82d16be5a353d913163f26fc4385e296be2b8
- https://git.kernel.org/stable/c/b5cc59470df64f26ad397dbb71cbf130cf489edf
- https://git.kernel.org/stable/c/be5f1a82ad6056db22c86005dc4cac22a20deeef
- https://git.kernel.org/stable/c/cf74d1197c0e3d2f353faa333e9e2847c73713f1
- https://git.kernel.org/stable/c/d581303d6f8d4139513105d73dd65f26c6707160
Modified: 2026-01-14
CVE-2022-50415
In the Linux kernel, the following vulnerability has been resolved: parisc: led: Fix potential null-ptr-deref in start_task() start_task() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: start_task() create_singlethread_workqueue() # failed, led_wq is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL.
- https://git.kernel.org/stable/c/3505c187b86136250b39e62c72a3a70435277af6
- https://git.kernel.org/stable/c/41f563ab3c33698bdfc3403c7c2e6c94e73681e4
- https://git.kernel.org/stable/c/5e4500454d75dd249be4695d83afa3ba0724c37e
- https://git.kernel.org/stable/c/67c98fec87ed76b1feb2ae810051afd88dfa9df6
- https://git.kernel.org/stable/c/77f8b628affaec692d83ad8bfa3520db8a0cc493
- https://git.kernel.org/stable/c/ac838c663ba1fd6bff35a817fd89a47ab55e88e0
- https://git.kernel.org/stable/c/c6db0c32f39684c89c97bc1ba1c9c4249ca09e48
- https://git.kernel.org/stable/c/fc307b2905a3dd75c50a53b4d87ac9c912fb7c4e
- https://git.kernel.org/stable/c/fc6d0f65f22040c6cc8a5ce032bf90252629de50
Modified: 2026-01-14
CVE-2022-50416
In the Linux kernel, the following vulnerability has been resolved: irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init() If of_iomap() failed, 'aic' should be freed before return. Otherwise there is a memory leak.
Modified: 2026-01-14
CVE-2022-50417
In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix GEM handle creation ref-counting panfrost_gem_create_with_handle() previously returned a BO but with the only reference being from the handle, which user space could in theory guess and release, causing a use-after-free. Additionally if the call to panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then a(nother) reference on the BO was dropped. The _create_with_handle() is a problematic pattern, so ditch it and instead create the handle in panfrost_ioctl_create_bo(). If the call to panfrost_gem_mapping_get() fails then this means that user space has indeed gone behind our back and freed the handle. In which case just return an error code.
- https://git.kernel.org/stable/c/0b70f6ea4d4f2b4d4b291d86ab76b4d07394932c
- https://git.kernel.org/stable/c/3f9feffa8a5ab08b4e298a27b1aa7204a7d42ca2
- https://git.kernel.org/stable/c/4217c6ac817451d5116687f3cc6286220dc43d49
- https://git.kernel.org/stable/c/4f1105ee72d8c7c35d90e3491b31b2d9d6b7e33a
- https://git.kernel.org/stable/c/ba3d2c2380e7129b525a787489c0b7e819a3b898
Modified: 2026-01-14
CVE-2022-50419
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times
device_add shall not be called multiple times as stated in its
documentation:
'Do not call this routine or device_register() more than once for
any device structure'
Syzkaller reports a bug as follows [1]:
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:33!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[...]
Call Trace:
- https://git.kernel.org/stable/c/1b6c89571f453101251201f0fad1c26f7256e937
- https://git.kernel.org/stable/c/3423a50fa018e88aed4c900d59c3c8334d8ad583
- https://git.kernel.org/stable/c/448a496f760664d3e2e79466aa1787e6abc922b5
- https://git.kernel.org/stable/c/4bcefec3636208b4c97536b26014d5935d5c10a0
- https://git.kernel.org/stable/c/6144423712d570247b8ca26e50a277c30dd13702
- https://git.kernel.org/stable/c/671fee73e08ff415d36a7c16bdf238927df83884
- https://git.kernel.org/stable/c/6e85d2ad958c6f034b1b158d904019869dbb3c81
- https://git.kernel.org/stable/c/7b674dce4162bb46d396586e30e4653427023875
- https://git.kernel.org/stable/c/ef055094df4c10b73cfe67c8d43f9de1fb608a8b
Modified: 2026-01-14
CVE-2022-50420
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/hpre - fix resource leak in remove process In hpre_remove(), when the disable operation of qm sriov failed, the following logic should continue to be executed to release the remaining resources that have been allocated, instead of returning directly, otherwise there will be resource leakage.
Modified: 2026-01-14
CVE-2022-50422
In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix use-after-free bug in smp_execute_task_sg() When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to delete "slow_task->timer". However, if the timer handler sas_task_internal_timedout() is running, the del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below: (thread 1) | (thread 2) smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ... sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the "task->slow_task" is deallocated.
- https://git.kernel.org/stable/c/117331a2a5227fb4369c2a1f321d3e3e2e2ef8fe
- https://git.kernel.org/stable/c/2e12ce270f0d926085c1209cc90397e307deef97
- https://git.kernel.org/stable/c/46ba53c30666717cb06c2b3c5d896301cd00d0c0
- https://git.kernel.org/stable/c/a9e5176ead6de64f572ad5c87a72825d9d3c82ae
- https://git.kernel.org/stable/c/e45a1516d2933703a4823d9db71e17c3abeba24f
- https://git.kernel.org/stable/c/f7a785177611ffc97d645fcbc196e6de6ad2421d
Modified: 2026-01-14
CVE-2022-50423
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()
There is an use-after-free reported by KASAN:
BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82
Read of size 1 at addr ffff888112afc460 by task modprobe/2111
CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
Call Trace:
- https://git.kernel.org/stable/c/01f2c2052ea50fb9a8ce12e4e83aed0267934ef0
- https://git.kernel.org/stable/c/02617006b5a46f2ea55ac61f5693c7afd7bf9276
- https://git.kernel.org/stable/c/02f237423c9c6a18e062de2d474f85d5659e4eb9
- https://git.kernel.org/stable/c/133462d35dae95edb944af86b986d4c9dec59bd1
- https://git.kernel.org/stable/c/470188b09e92d83c5a997f25f0e8fb8cd2bc3469
- https://git.kernel.org/stable/c/6fde666278f91b85d71545a0ebbf41d8d7af8074
- https://git.kernel.org/stable/c/c9125b643fc51b8e662f2f614096ceb45a0adbc3
- https://git.kernel.org/stable/c/dfdde4d5138bc023897033a5ac653a84e94805be
- https://git.kernel.org/stable/c/f51b2235e4f320edc839c3e5cb0d1f8a6e8657c6
Modified: 2026-01-20
CVE-2022-50427
In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: fix possible memory leak in snd_ac97_dev_register() If device_register() fails in snd_ac97_dev_register(), it should call put_device() to give up reference, or the name allocated in dev_set_name() is leaked.
- https://git.kernel.org/stable/c/0f8e9a15c8ecf95057061d370a2dddaf1cee4aeb
- https://git.kernel.org/stable/c/4881bda5ea05c8c240fc8afeaa928e2bc43f61fa
- https://git.kernel.org/stable/c/4fdf6f978c6b605ca0d67bf0e982b7a8fc0f4aab
- https://git.kernel.org/stable/c/758dbcc6fbf2286eff02743b093c70a18a407d66
- https://git.kernel.org/stable/c/a602ec9d88f177dba78bc97fb1adecc7a71ff279
- https://git.kernel.org/stable/c/bfce73088682ef0770da951f51156c36a89be490
- https://git.kernel.org/stable/c/c68b2e9ef246117f696e360bbdd2f5736b3a7127
- https://git.kernel.org/stable/c/ee8bf0946f62ef00e5db4b613a9f664ac567259a
Modified: 2026-01-20
CVE-2022-50428
In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one errors in fast-commit block filling Due to several different off-by-one errors, or perhaps due to a late change in design that wasn't fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries: - tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn't seem to happen currently.) - tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks. Also, strangely these constraints don't apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...). Given that this all seems to be a bug, let's fix it by just filling blocks with tlv entries in the natural way. Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit.
Modified: 2026-01-21
CVE-2022-50429
In the Linux kernel, the following vulnerability has been resolved: memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount.
- https://git.kernel.org/stable/c/1d312c12c91f831fcc48623c921f2d4560edb159
- https://git.kernel.org/stable/c/3b321bf7687968a090cf6b62bd8e67d692f59a16
- https://git.kernel.org/stable/c/48af14fb0eaa63d9aa68f59fb0b205ec55a95636
- https://git.kernel.org/stable/c/7e053784c4c70df28324106d476778be7a4519b3
- https://git.kernel.org/stable/c/daab421fc2dc7d6ae7eb20a3f565ae09652c68b9
Modified: 2026-01-21
CVE-2022-50430
In the Linux kernel, the following vulnerability has been resolved:
mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING
vub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here.
Ensure that we mark current as TASK_RUNNING for sleepable context.
[ 77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [
- https://git.kernel.org/stable/c/32d5af247d4de6a35769ca1d027480a37c28fd0c
- https://git.kernel.org/stable/c/48e91ae755f027d817ed7e51db9963ddb7081946
- https://git.kernel.org/stable/c/4a44cd249604e29e7b90ae796d7692f5773dd348
- https://git.kernel.org/stable/c/6f7258c6f66692b3760c37ddd4bc9e02bb290da7
- https://git.kernel.org/stable/c/b51d5fed9f53e07ce9fc65efb4ff1abe021a4c16
- https://git.kernel.org/stable/c/ba2e7d07dd06e646a72ba906a89fdc1cca7ea560
- https://git.kernel.org/stable/c/d15946ef98f4ccdca961b76f90d9b53c454d590e
- https://git.kernel.org/stable/c/d58289fc77f8c1f879c818bddaf7ef524c73658b
- https://git.kernel.org/stable/c/f1c08947ab0538b07a0bd9d6edadfb5185f56344
Modified: 2026-01-20
CVE-2022-50431
In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev() dev_set_name() in soundbus_add_one() allocates memory for name, it need be freed when of_device_register() fails, call soundbus_dev_put() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. And other resources are also freed in i2sbus_release_dev(), so it can return 0 directly.
- https://git.kernel.org/stable/c/027fee10e3a400cf6f3237374a1248da1082807b
- https://git.kernel.org/stable/c/4a4c8482e370d697738a78dcd7bf2780832cb712
- https://git.kernel.org/stable/c/5bdea674534153110b90d70b02f2fbaf48b2c0eb
- https://git.kernel.org/stable/c/802532a50acf501fdafe38a84ca2aa886d68af68
- https://git.kernel.org/stable/c/c7524279c8ddc7dbf3463bec70e0289097959944
- https://git.kernel.org/stable/c/ce6fd1c382a38b75557db85a2fe99d285540a03d
- https://git.kernel.org/stable/c/e81d7826b8f40430a1ea1b330e24d9a9eb4512c4
- https://git.kernel.org/stable/c/fd410d24665e4efb3c1796797181265efe553e9c
Modified: 2026-01-20
CVE-2022-50432
In the Linux kernel, the following vulnerability has been resolved:
kernfs: fix use-after-free in __kernfs_remove
Syzkaller managed to trigger concurrent calls to
kernfs_remove_by_name_ns() for the same file resulting in
a KASAN detected use-after-free. The race occurs when the root
node is freed during kernfs_drain().
To prevent this acquire an additional reference for the root
of the tree that is removed before calling __kernfs_remove().
Found by syzkaller with the following reproducer (slab_nomerge is
required):
syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0)
r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0)
close(r0)
pipe2(&(0x7f0000000140)={0xffffffffffffffff,
- https://git.kernel.org/stable/c/028cf780743eea79abffa7206b9dcfc080ad3546
- https://git.kernel.org/stable/c/02eb35131050735332658029082f61515b7dfe38
- https://git.kernel.org/stable/c/4abc99652812a2ddf932f137515d5c5a04723538
- https://git.kernel.org/stable/c/4dfd6a477a1525773469feaf3c514b2c0fef76b5
- https://git.kernel.org/stable/c/6f72a3977ba9d0e5491a5c01315204272e7f9c44
- https://git.kernel.org/stable/c/94d2643df1e70a4c310ebb5e2c493eec33df1a06
- https://git.kernel.org/stable/c/af1b57cc39beca203559576b3046094fc9e5eb32
- https://git.kernel.org/stable/c/c78b0dc6fb7fb389d674e491fd376388cdfb1d53
Modified: 2026-01-23
CVE-2022-50434
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix possible memleak when register 'hctx' failed There's issue as follows when do fault injection test: unreferenced object 0xffff888132a9f400 (size 512): comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2.... 08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............ backtrace: [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0 [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0 [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230 [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910 [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0 [<00000000a2a34657>] 0xffffffffa2ad310f [<00000000b173f718>] 0xffffffffa2af824a [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0 [<00000000f32fdf93>] do_init_module+0xdf/0x320 [<00000000cbe8541e>] load_module+0x3006/0x3390 [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0 [<00000000a1a29ae8>] do_syscall_64+0x35/0x80 [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fault injection context as follows: kobject_add blk_mq_register_hctx blk_mq_sysfs_register blk_register_queue device_add_disk null_add_dev.part.0 [null_blk] As 'blk_mq_register_hctx' may already add some objects when failed halfway, but there isn't do fallback, caller don't know which objects add failed. To solve above issue just do fallback when add objects failed halfway in 'blk_mq_register_hctx'.
- https://git.kernel.org/stable/c/02bc8bc6eab03c84373281b85cb6e98747172ff7
- https://git.kernel.org/stable/c/33e8a3f61814ea30615d0fafaf50477975d6c1ca
- https://git.kernel.org/stable/c/4b7a21c57b14fbcd0e1729150189e5933f5088e9
- https://git.kernel.org/stable/c/4b7fafa5f39b15c3a6ca3b95e534d05d6904cc95
- https://git.kernel.org/stable/c/654870789c3c1b9763316ef1c71d7a449127b175
- https://git.kernel.org/stable/c/87fd18016a47ea8ae12641377a390172c4aa97a7
- https://git.kernel.org/stable/c/cb186eb47fb9dd327bdefa15f0c5fc55c53a40dd
- https://git.kernel.org/stable/c/e8022da1fa2fdf2fa204b445dd3354e7a66d085a
- https://git.kernel.org/stable/c/eff45bfbc25a2509a6362dea6e699e14083c693c
Modified: 2026-01-21
CVE-2022-50435
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid crash when inline data creation follows DIO write
When inode is created and written to using direct IO, there is nothing
to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets
truncated later to say 1 byte and written using normal write, we will
try to store the data as inline data. This confuses the code later
because the inode now has both normal block and inline data allocated
and the confusion manifests for example as:
kernel BUG at fs/ext4/inode.c:2721!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
RIP: 0010:ext4_writepages+0x363d/0x3660
RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293
RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180
RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000
RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b
R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128
R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001
FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0
Call Trace:
- https://git.kernel.org/stable/c/4bb26f2885ac6930984ee451b952c5a6042f2c0e
- https://git.kernel.org/stable/c/771f15782d95760cde352c8d4bfd6f2c70719568
- https://git.kernel.org/stable/c/89db2b50469bdbccb06ab072096d9d403124abac
- https://git.kernel.org/stable/c/d8e4af8314df54d94cf2a541cf9c8626afe81d41
- https://git.kernel.org/stable/c/fb98cb61efff3b2a1964939465ccaaf906af1d4f
Modified: 2026-01-21
CVE-2022-50436
In the Linux kernel, the following vulnerability has been resolved: ext4: don't set up encryption key during jbd2 transaction Commit a80f7fcf1867 ("ext4: fixup ext4_fc_track_* functions' signature") extended the scope of the transaction in ext4_unlink() too far, making it include the call to ext4_find_entry(). However, ext4_find_entry() can deadlock when called from within a transaction because it may need to set up the directory's encryption key. Fix this by restoring the transaction to its original scope.
- https://git.kernel.org/stable/c/1ba993208bcfd691e241483420a2a761d3f15750
- https://git.kernel.org/stable/c/206dd3acfb9bca54a25b228c7c7c2257eedde09b
- https://git.kernel.org/stable/c/23ad034760dd38e12b0e0e1b28b9629f330810a1
- https://git.kernel.org/stable/c/4c0d5778385cb3618ff26a561ce41de2b7d9de70
- https://git.kernel.org/stable/c/6220ec405571ded17efedc56587190b542adf246
Modified: 2026-01-21
CVE-2022-50437
In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502670/
- https://git.kernel.org/stable/c/08c7375fa27a8ceee028868e03ffb3a0db919d44
- https://git.kernel.org/stable/c/3c43f3ec731c233eb84b66199ee76dbf3ec6ecae
- https://git.kernel.org/stable/c/4c1294da6aed1f16d47a417dcfe6602833c3c95c
- https://git.kernel.org/stable/c/9efb45b45ff6254bfd1f1997a06725cb3fc998a5
- https://git.kernel.org/stable/c/a9c1a6991a9b5aa6d0f2cbc9b8c3bf6c4d094dfa
- https://git.kernel.org/stable/c/b48949ab451eaf1e2c04c272c8a9a96a2b56546f
- https://git.kernel.org/stable/c/e8f916b84e4b028ecad6c6472eaad543cc7df806
- https://git.kernel.org/stable/c/ed7f1ff87a4afea1bc220d2ff00a7ce8e61f0b53
Modified: 2026-01-21
CVE-2022-50438
In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix memory leak when reading function table When the input parameter idx meets the expected case option in hinic_dbg_get_func_table(), read_data is not released. Fix it.
Modified: 2026-01-21
CVE-2022-50439
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8173: Enable IRQ when pdata is ready If the device does not come straight from reset, we might receive an IRQ before we are ready to handle it. [ 2.334737] Unable to handle kernel read from unreadable memory at virtual address 00000000000001e4 [ 2.522601] Call trace: [ 2.525040] regmap_read+0x1c/0x80 [ 2.528434] mt8173_afe_irq_handler+0x40/0xf0 ... [ 2.598921] start_kernel+0x338/0x42c
- https://git.kernel.org/stable/c/190685ff4ee03eef8f12c71d8f626e414fa078a9
- https://git.kernel.org/stable/c/27e7cf595d4a9fea9d3906b47d0faa87896beeb3
- https://git.kernel.org/stable/c/4cbb264d4e9136acab2c8fd39e39ab1b1402b84b
- https://git.kernel.org/stable/c/57491967ad8f865a9a81d08c36b26facd14d84e5
- https://git.kernel.org/stable/c/77c6b6be7e80ca4a4d4b66b63fd5bb48ccefdd5a
- https://git.kernel.org/stable/c/9ce9c78a2bdbc9a014e7102a35834310c28528b9
Modified: 2026-01-21
CVE-2022-50440
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate the box size for the snooped cursor Invalid userspace dma surface copies could potentially overflow the memcpy from the surface to the snooped image leading to crashes. To fix it the dimensions of the copybox have to be validated against the expected size of the snooped cursor.
- https://git.kernel.org/stable/c/439cbbc1519547f9a7b483f0de33b556ebfec901
- https://git.kernel.org/stable/c/4cf949c7fafe21e085a4ee386bb2dade9067316e
- https://git.kernel.org/stable/c/4d54d11b49860686331c58a00f733b16a93edfc4
- https://git.kernel.org/stable/c/50d177f90b63ea4138560e500d92be5e4c928186
- https://git.kernel.org/stable/c/622d527decaac0eb65512acada935a0fdc1d0202
- https://git.kernel.org/stable/c/6948e570f54f2044dd4da444b10471373a047eeb
- https://git.kernel.org/stable/c/6b4e70a428b5a11f56db94047b68e144529fe512
- https://git.kernel.org/stable/c/94b283341f9f3f0ed56a360533766377a01540e0
- https://git.kernel.org/stable/c/ee8d31836cbe7c26e207bfa0a4a726f0a25cfcf6
Modified: 2026-01-20
CVE-2022-50442
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate buffer length while parsing index
indx_read is called when we have some NTFS directory operations that
need more information from the index buffers. This adds a sanity check
to make sure the returned index buffer length is legit, or we may have
some out-of-bound memory accesses.
[ 560.897595] BUG: KASAN: slab-out-of-bounds in hdr_find_e.isra.0+0x10c/0x320
[ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245
[ 560.898760]
[ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37
[ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 560.900170] Call Trace:
[ 560.900407]
Modified: 2026-01-16
CVE-2022-50443
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: lvds: fix PM usage counter unbalance in poweron pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with the newest pm_runtime_resume_and_get to keep usage counter balanced.
- https://git.kernel.org/stable/c/110bf15825edf4f20bc4e56aba624297861b06ab
- https://git.kernel.org/stable/c/12a9b4c4ebd9a0ba856370e088564af83cffd565
- https://git.kernel.org/stable/c/4dba27f1a14592ac4cf71c3bc1cc1fd05dea8015
- https://git.kernel.org/stable/c/589a911980b730feadb9c430bc0747a118b04dd8
- https://git.kernel.org/stable/c/f6ed73db390319b248b91a6325da1a48ad85e0d1
Modified: 2026-01-16
CVE-2022-50444
In the Linux kernel, the following vulnerability has been resolved: clk: tegra20: Fix refcount leak in tegra20_clock_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/0172d14f50098f5736b4b272a1529a3e05419bd6
- https://git.kernel.org/stable/c/4e343bafe03ff68a62f48f8235cf98f2c685468b
- https://git.kernel.org/stable/c/53531d00e2a8a28a3bf56ea58b18ff3611824f37
- https://git.kernel.org/stable/c/5d9fb09612defe7b1d5627db7b3833b46eb21e7b
- https://git.kernel.org/stable/c/6f76ef65899fcd93ca747ef38d7a41931e61e4fa
- https://git.kernel.org/stable/c/70f0a0a27d79f689defc5f5f0bd47d07813e6dea
- https://git.kernel.org/stable/c/8cd228892759d37f36a46616025f4fa0d0a63b5d
- https://git.kernel.org/stable/c/d6e750535b46e12cdde185b416c415e49e4e6e22
- https://git.kernel.org/stable/c/f9bdef9bb60814514a787b84184ecaa269a7c951
Modified: 2026-01-16
CVE-2022-50445
In the Linux kernel, the following vulnerability has been resolved: xfrm: Reinject transport-mode packets through workqueue The following warning is displayed when the tcp6-multi-diffip11 stress test case of the LTP test suite is tested: watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198] CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : des3_ede_encrypt+0x27c/0x460 [libdes] lr : 0x3f sp : ffff80000ceaa1b0 x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280 x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b x23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038 x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033 x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248 x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548 x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748 x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b x5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3 x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872 Call trace: des3_ede_encrypt+0x27c/0x460 [libdes] crypto_des3_ede_encrypt+0x1c/0x30 [des_generic] crypto_cbc_encrypt+0x148/0x190 crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_rcv_established+0x3c8/0x720 tcp_v6_do_rcv+0xdc/0x4a0 tcp_v6_rcv+0xc24/0xcb0 ip6_protocol_deliver_rcu+0xf0/0x574 ip6_input_finish+0x48/0x7c ip6_input+0x48/0xc0 ip6_rcv_finish+0x80/0x9c xfrm_trans_reinject+0xb0/0xf4 tasklet_action_common.constprop.0+0xf8/0x134 tasklet_action+0x30/0x3c __do_softirq+0x128/0x368 do_softirq+0xb4/0xc0 __local_bh_enable_ip+0xb0/0xb4 put_cpu_fpsimd_context+0x40/0x70 kernel_neon_end+0x20/0x40 sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce] sha1_ce_finup+0x94/0x110 [sha1_ce] crypto_shash_finup+0x34/0xc0 hmac_finup+0x48/0xe0 crypto_shash_finup+0x34/0xc0 shash_digest_unaligned+0x74/0x90 crypto_shash_digest+0x4c/0x9c shash_ahash_digest+0xc8/0xf0 shash_async_digest+0x28/0x34 crypto_ahash_digest+0x48/0xcc crypto_authenc_genicv+0x88/0xcc [authenc] crypto_authenc_encrypt+0xd8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_push+0xb4/0x14c tcp_sendmsg_locked+0x71c/0xb64 tcp_sendmsg+0x40/0x6c inet6_sendmsg+0x4c/0x80 sock_sendmsg+0x5c/0x6c __sys_sendto+0x128/0x15c __arm64_sys_sendto+0x30/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x170/0x194 do_el0_svc+0x38/0x4c el0_svc+0x28/0xe0 el0t_64_sync_handler+0xbc/0x13c el0t_64_sync+0x180/0x184 Get softirq info by bcc tool: ./softirqs -NT 10 Tracing soft irq event time... Hit Ctrl-C to end. 15:34:34 SOFTIRQ TOTAL_nsecs block 158990 timer 20030920 sched 46577080 net_rx 676746820 tasklet 9906067650 15:34:45 SOFTIRQ TOTAL_nsecs block 86100 sched 38849790 net_rx ---truncated---
Modified: 2026-01-16
CVE-2022-50446
In the Linux kernel, the following vulnerability has been resolved: ARC: mm: fix leakage of memory allocated for PTE Since commit d9820ff ("ARC: mm: switch pgtable_t back to struct page *") a memory leakage problem occurs. Memory allocated for page table entries not released during process termination. This issue can be reproduced by a small program that allocates a large amount of memory. After several runs, you'll see that the amount of free memory has reduced and will continue to reduce after each run. All ARC CPUs are effected by this issue. The issue was introduced since the kernel stable release v5.15-rc1. As described in commit d9820ff after switch pgtable_t back to struct page *, a pointer to "struct page" and appropriate functions are used to allocate and free a memory page for PTEs, but the pmd_pgtable macro hasn't changed and returns the direct virtual address from the PMD (PGD) entry. Than this address used as a parameter in the __pte_free() and as a result this function couldn't release memory page allocated for PTEs. Fix this issue by changing the pmd_pgtable macro and returning pointer to struct page.
Modified: 2026-01-16
CVE-2022-50449
In the Linux kernel, the following vulnerability has been resolved: clk: samsung: Fix memory leak in _samsung_clk_register_pll() If clk_register() fails, @pll->rate_table may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it.
- https://git.kernel.org/stable/c/2e8dc0626fe86ae08914478dec1419618c557bc0
- https://git.kernel.org/stable/c/4887ec922e407b4feaf060c7b099482a5c52dee3
- https://git.kernel.org/stable/c/4e501a31af8efa593a2f003637b56d00b75dca23
- https://git.kernel.org/stable/c/5174e5b0d1b669a489524192b6adcbb3c54ebc72
- https://git.kernel.org/stable/c/7b738276a596fa101d320591e9fa84ea0fc3f713
- https://git.kernel.org/stable/c/a00b4e0fa27317957536abf8f5d6a96d6cb9d9be
- https://git.kernel.org/stable/c/a35323218ff32782d051d2643912311a22e07b6a
- https://git.kernel.org/stable/c/da13355bb9961316d124f94dfc7a1385d0fb035a
Modified: 2026-01-16
CVE-2022-50451
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix memory leak on ntfs_fill_super() error path
syzbot reported kmemleak as below:
BUG: memory leak
unreferenced object 0xffff8880122f1540 (size 32):
comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 ed ff ed ff 00 00 00 00 ................
backtrace:
[
Modified: 2026-01-16
CVE-2022-50452
In the Linux kernel, the following vulnerability has been resolved:
net: sched: cake: fix null pointer access issue when cake_init() fails
When the default qdisc is cake, if the qdisc of dev_queue fails to be
inited during mqprio_init(), cake_reset() is invoked to clear
resources. In this case, the tins is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
cake_init()
q->tins = kvcalloc(...) --->failed, q->tins is NULL
...
qdisc_put()
...
cake_reset()
...
cake_dequeue_one()
b = &q->tins[...] --->q->tins is NULL
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:cake_dequeue_one+0xc9/0x3c0
Call Trace:
- https://git.kernel.org/stable/c/154f4c06d9dbec1a14e91286c70b6305810302e0
- https://git.kernel.org/stable/c/1dc0a019550fd38ec6cab2d73c90df2bd659c96b
- https://git.kernel.org/stable/c/51f9a8921ceacd7bf0d3f47fa867a64988ba1dcb
- https://git.kernel.org/stable/c/86aa1390898146f1de277bb6d2a8ed7fc7a43f12
- https://git.kernel.org/stable/c/ae48bee2830bf216800e1447baca39541e27a12e
- https://git.kernel.org/stable/c/bc8301ea7e7f1bb9d2ba2fcdf7b5ec2f0792b47e
Modified: 2026-01-16
CVE-2022-50453
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix NULL-pointer dereferences There are several places where we can crash the kernel by requesting lines, unbinding the GPIO device, then calling any of the system calls relevant to the GPIO character device's annonymous file descriptors: ioctl(), read(), poll(). While I observed it with the GPIO simulator, it will also happen for any of the GPIO devices that can be hot-unplugged - for instance any HID GPIO expander (e.g. CP2112). This affects both v1 and v2 uAPI. This fixes it partially by checking if gdev->chip is not NULL but it doesn't entirely remedy the situation as we still have a race condition in which another thread can remove the device after the check.
- https://git.kernel.org/stable/c/533aae7c94dbc2b14301cfd68ae7e0e90f0c8438
- https://git.kernel.org/stable/c/6d79546622baab843172b52c3af035f83c1b21df
- https://git.kernel.org/stable/c/7c755a2d6df511eeb5afba966ac28140f9ea5063
- https://git.kernel.org/stable/c/ac6ce3cd7a3e10a2e37b8970bab81b4d33d5cfc3
- https://git.kernel.org/stable/c/d66f68ac9e7ba46b6b90fbe25155723f2126088a
Modified: 2026-01-16
CVE-2022-50454
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in nouveau_gem_prime_import_sg_table() nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm will call nouveau_bo_del_ttm() and free the memory.Thus, when nouveau_bo_init() returns an error, the gem object has already been released. Then the call to nouveau_bo_ref() will use the freed "nvbo->bo" and lead to a use-after-free bug. We should delete the call to nouveau_bo_ref() to avoid the use-after-free.
- https://git.kernel.org/stable/c/3aeda2fe6517cc52663d4ce3588dd43f0d4124a7
- https://git.kernel.org/stable/c/540dfd188ea2940582841c1c220bd035a7db0e51
- https://git.kernel.org/stable/c/56ee9577915dc06f55309901012a9ef68dbdb5a8
- https://git.kernel.org/stable/c/5d6093c49c098d86c7b136aba9922df44aeb6944
- https://git.kernel.org/stable/c/7d80473e9f12548ac05b36af4fb9ce80f2f73509
- https://git.kernel.org/stable/c/861f085f81fd569b02cc2c11165a9e6cca144424
Modified: 2026-01-16
CVE-2022-50456
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix resolving backrefs for inline extent followed by prealloc If a file consists of an inline extent followed by a regular or prealloc extent, then a legitimate attempt to resolve a logical address in the non-inline region will result in add_all_parents reading the invalid offset field of the inline extent. If the inline extent item is placed in the leaf eb s.t. it is the first item, attempting to access the offset field will not only be meaningless, it will go past the end of the eb and cause this panic: [17.626048] BTRFS warning (device dm-2): bad eb member end: ptr 0x3fd4 start 30834688 member offset 16377 size 8 [17.631693] general protection fault, probably for non-canonical address 0x5088000000000: 0000 [#1] SMP PTI [17.635041] CPU: 2 PID: 1267 Comm: btrfs Not tainted 5.12.0-07246-g75175d5adc74-dirty #199 [17.637969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [17.641995] RIP: 0010:btrfs_get_64+0xe7/0x110 [17.649890] RSP: 0018:ffffc90001f73a08 EFLAGS: 00010202 [17.651652] RAX: 0000000000000001 RBX: ffff88810c42d000 RCX: 0000000000000000 [17.653921] RDX: 0005088000000000 RSI: ffffc90001f73a0f RDI: 0000000000000001 [17.656174] RBP: 0000000000000ff9 R08: 0000000000000007 R09: c0000000fffeffff [17.658441] R10: ffffc90001f73790 R11: ffffc90001f73788 R12: ffff888106afe918 [17.661070] R13: 0000000000003fd4 R14: 0000000000003f6f R15: cdcdcdcdcdcdcdcd [17.663617] FS: 00007f64e7627d80(0000) GS:ffff888237c80000(0000) knlGS:0000000000000000 [17.666525] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [17.668664] CR2: 000055d4a39152e8 CR3: 000000010c596002 CR4: 0000000000770ee0 [17.671253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [17.673634] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [17.676034] PKRU: 55555554 [17.677004] Call Trace: [17.677877] add_all_parents+0x276/0x480 [17.679325] find_parent_nodes+0xfae/0x1590 [17.680771] btrfs_find_all_leafs+0x5e/0xa0 [17.682217] iterate_extent_inodes+0xce/0x260 [17.683809] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.685597] ? iterate_inodes_from_logical+0xa1/0xd0 [17.687404] iterate_inodes_from_logical+0xa1/0xd0 [17.689121] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.691010] btrfs_ioctl_logical_to_ino+0x131/0x190 [17.692946] btrfs_ioctl+0x104a/0x2f60 [17.694384] ? selinux_file_ioctl+0x182/0x220 [17.695995] ? __x64_sys_ioctl+0x84/0xc0 [17.697394] __x64_sys_ioctl+0x84/0xc0 [17.698697] do_syscall_64+0x33/0x40 [17.700017] entry_SYSCALL_64_after_hwframe+0x44/0xae [17.701753] RIP: 0033:0x7f64e72761b7 [17.709355] RSP: 002b:00007ffefb067f58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [17.712088] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f64e72761b7 [17.714667] RDX: 00007ffefb067fb0 RSI: 00000000c0389424 RDI: 0000000000000003 [17.717386] RBP: 00007ffefb06d188 R08: 000055d4a390d2b0 R09: 00007f64e7340a60 [17.719938] R10: 0000000000000231 R11: 0000000000000246 R12: 0000000000000001 [17.722383] R13: 0000000000000000 R14: 00000000c0389424 R15: 000055d4a38fd2a0 [17.724839] Modules linked in: Fix the bug by detecting the inline extent item in add_all_parents and skipping to the next extent item.
- https://git.kernel.org/stable/c/0061ab5153fb8bc574b44fbb773680d0ede48c9c
- https://git.kernel.org/stable/c/560840afc3e63bbe5d9c5ef6b2ecf8f3589adff6
- https://git.kernel.org/stable/c/645e2dac6e97f756f28a2f82b2e7bf7f29a68827
- https://git.kernel.org/stable/c/99590f29b2b7567fda2b503aa3d81a0d3e09dce5
- https://git.kernel.org/stable/c/a94b90ac1f251d1007c0c43ee289a61b50f2505f
- https://git.kernel.org/stable/c/c59ee1528b3432ec9dca220567f7eb507820917a
Modified: 2026-01-16
CVE-2022-50458
In the Linux kernel, the following vulnerability has been resolved: clk: tegra: Fix refcount leak in tegra210_clock_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1a6d97139b0a370a9d0809a00e91c41f5bcd3ef1
- https://git.kernel.org/stable/c/417ed4432b1b40526b1cb50e535d46900505f6d9
- https://git.kernel.org/stable/c/56c78cb1f00a9dde8cd762131ce8f4c5eb046fbb
- https://git.kernel.org/stable/c/6d3ac23b952f374017e1a5249d1f03bdbc7f9878
- https://git.kernel.org/stable/c/a19360db83d29bd6b0de4ffad2c815d79246ba99
- https://git.kernel.org/stable/c/ac010ec3484ba95c6ab3d946f9a83560005c13c6
- https://git.kernel.org/stable/c/e715510adc20a4a07f157ece4e6d068e648a0383
- https://git.kernel.org/stable/c/f38f34ba1e1029b927b81b9bf9d952f4ed4007bd
- https://git.kernel.org/stable/c/f487137a53b1a0692211f7ae82c0a7f87c30bdbe
Modified: 2026-01-16
CVE-2022-50459
In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername() Fix a NULL pointer crash that occurs when we are freeing the socket at the same time we access it via sysfs. The problem is that: 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold() does a get on the "struct sock". 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put on the "struct socket" and that does __sock_release() which sets the sock->ops to NULL. 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then call kernel_getpeername() which accesses the NULL sock->ops. Above we do a get on the "struct sock", but we needed a get on the "struct socket". Originally, we just held the frwd_lock the entire time but in commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while calling getpeername()") we switched to refcount based because the network layer changed and started taking a mutex in that path, so we could no longer hold the frwd_lock. Instead of trying to maintain multiple refcounts, this just has us use a mutex for accessing the socket in the interface code paths.
- https://git.kernel.org/stable/c/0a0b861fce2657ba08ec356a74346b37ca4b2008
- https://git.kernel.org/stable/c/57569c37f0add1b6489e1a1563c71519daf732cf
- https://git.kernel.org/stable/c/884a788f065578bb640382279a83d1df433b13e6
- https://git.kernel.org/stable/c/897dbbc57d71e8a34ec1af8e573a142de457da38
- https://git.kernel.org/stable/c/a26b0658751bb0a3b28386fca715333b104d32a2
Modified: 2026-01-16
CVE-2022-50460
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix xid leak in cifs_flock() If not flock, before return -ENOLCK, should free the xid, otherwise, the xid will be leaked.
Modified: 2026-01-16
CVE-2022-50462
In the Linux kernel, the following vulnerability has been resolved: MIPS: vpe-mt: fix possible memory leak while module exiting Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, it need be freed when module exiting, call put_device() to give up reference, so that it can be freed in kobject_cleanup() when the refcount hit to 0. The vpe_device is static, so remove kfree() from vpe_device_release().
- https://git.kernel.org/stable/c/170e9913c2ed5cfc37c0adf0fdbd368d2d8d8168
- https://git.kernel.org/stable/c/48d42f4464d713fbdd79f334fdcd6e5be534cc67
- https://git.kernel.org/stable/c/5822e8cc84ee37338ab0bdc3124f6eec04dc232d
- https://git.kernel.org/stable/c/851ae5640875f06494e40002cd503b11a634c6fb
- https://git.kernel.org/stable/c/9d180e0bb21c57bd6cca2adeb672d3b522e910b5
- https://git.kernel.org/stable/c/ab3d47c1fd0202821abd473ca87580faafd47847
- https://git.kernel.org/stable/c/b191dde84e40624d5577f64db0ec922c5c0ec57c
- https://git.kernel.org/stable/c/b3325a443525e3b89151879b834519b21c5e3011
- https://git.kernel.org/stable/c/e820a8192ff68570100347855b567512aec43819
Modified: 2026-01-16
CVE-2022-50463
In the Linux kernel, the following vulnerability has been resolved: powerpc/52xx: Fix a resource leak in an error handling path The error handling path of mpc52xx_lpbfifo_probe() has a request_irq() that is not balanced by a corresponding free_irq(). Add the missing call, as already done in the remove function.
- https://git.kernel.org/stable/c/0accd460dc7bbe5f55e41a8867c63db9d07b3ec8
- https://git.kernel.org/stable/c/40b4be399e0db7073dec5a0de5ca9994f7e31e58
- https://git.kernel.org/stable/c/5836947613ef33d311b4eff6a32d019580a214f5
- https://git.kernel.org/stable/c/9bf842ffdd216b9f94d5b051b5d8b815f2426538
- https://git.kernel.org/stable/c/be9caf2c936f15a9c3f9111e62bdde6357312f90
- https://git.kernel.org/stable/c/cbda93665a3857324f5c79e45769a83c78183199
- https://git.kernel.org/stable/c/e4002f293e5b44e57d2930513cca0dff32249812
- https://git.kernel.org/stable/c/f4ad0a7f0e78d65d38921ab2bef234e49be78b10
- https://git.kernel.org/stable/c/fb3ef6a5af4b003502c940ea50c0f55b06ebbfc9
Modified: 2026-01-16
CVE-2022-50465
In the Linux kernel, the following vulnerability has been resolved: ext4: fix leaking uninitialized memory in fast-commit journal When space at the end of fast-commit journal blocks is unused, make sure to zero it out so that uninitialized memory is not leaked to disk.
- https://git.kernel.org/stable/c/594bc43b410316d70bb42aeff168837888d96810
- https://git.kernel.org/stable/c/7c1fb65e8ce85c281d2cba9c236f9edbbc4eaca6
- https://git.kernel.org/stable/c/871800770d7f2f952c7249ad52485c3564dab44e
- https://git.kernel.org/stable/c/b8b7922374b00a44137e5bcdd46ef86c8b065f27
- https://git.kernel.org/stable/c/d9ba03eb03dc2dccb5450de388ea46bdcaaf8348
Modified: 2026-01-16
CVE-2022-50466
In the Linux kernel, the following vulnerability has been resolved:
fs/binfmt_elf: Fix memory leak in load_elf_binary()
There is a memory leak reported by kmemleak:
unreferenced object 0xffff88817104ef80 (size 224):
comm "xfs_admin", pid 47165, jiffies 4298708825 (age 1333.476s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60 a8 b3 00 81 88 ff ff a8 10 5a 00 81 88 ff ff `.........Z.....
backtrace:
[
Modified: 2026-01-16
CVE-2022-50468
In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()
The following WARNING message was given when rmmod cros_usbpd_notify:
Unexpected driver unregister!
WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0
Modules linked in: cros_usbpd_notify(-)
CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24
...
Call Trace:
- https://git.kernel.org/stable/c/5a2d96623670155d94aca72c320c0ac27bdc6bd2
- https://git.kernel.org/stable/c/5c0cacdd354987f8f5348d16908716f154047890
- https://git.kernel.org/stable/c/751f12696d797e785d2611099fe9f0569d47556e
- https://git.kernel.org/stable/c/7b6ee54995739202b4a0cc01b7e9269f761c573d
- https://git.kernel.org/stable/c/cab345f9d51943898e406275f9607c145adb1877
Modified: 2026-01-16
CVE-2022-50469
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix potential memory leak in rtw_init_drv_sw() In rtw_init_drv_sw(), there are various init functions are called to populate the padapter structure and some checks for their return value. However, except for the first one error path, the other five error paths do not properly release the previous allocated resources, which leads to various memory leaks. This patch fixes them and keeps the success and error separate. Note that these changes keep the form of `rtw_init_drv_sw()` in "drivers/staging/r8188eu/os_dep/os_intfs.c". As there is no proper device to test with, no runtime testing was performed.
Modified: 2026-01-23
CVE-2022-50470
In the Linux kernel, the following vulnerability has been resolved: xhci: Remove device endpoints from bandwidth list when freeing the device Endpoints are normally deleted from the bandwidth list when they are dropped, before the virt device is freed. If xHC host is dying or being removed then the endpoints aren't dropped cleanly due to functions returning early to avoid interacting with a non-accessible host controller. So check and delete endpoints that are still on the bandwidth list when freeing the virt device. Solves a list_del corruption kernel crash when unbinding xhci-pci, caused by xhci_mem_cleanup() when it later tried to delete already freed endpoints from the bandwidth list. This only affects hosts that use software bandwidth checking, which currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)
- https://git.kernel.org/stable/c/3bf860a41e0f2fcea0ac3aae8f7ef887a7994b70
- https://git.kernel.org/stable/c/5aed5b7c2430ce318a8e62f752f181e66f0d1053
- https://git.kernel.org/stable/c/5e4ce28ad907aa54f13b21d5f1dc490525957b0c
- https://git.kernel.org/stable/c/678d2cc2041cc6ce05030852dce9ad42719abcfc
- https://git.kernel.org/stable/c/8f1cd9633d1f21efc13e8fc75be8f2b6bb85e38c
- https://git.kernel.org/stable/c/c892a81c7424b4f6a660cb9c249d354ccf3afeca
- https://git.kernel.org/stable/c/cebbc8d335d6bcc1316584f779c08f80287c6af8
- https://git.kernel.org/stable/c/f0de39474078adef6ece7a183e34c15ce2c1d8d1
Modified: 2026-01-23
CVE-2022-50471
In the Linux kernel, the following vulnerability has been resolved:
xen/gntdev: Accommodate VMA splitting
Prior to this commit, the gntdev driver code did not handle the
following scenario correctly with paravirtualized (PV) Xen domains:
* User process sets up a gntdev mapping composed of two grant mappings
(i.e., two pages shared by another Xen domain).
* User process munmap()s one of the pages.
* User process munmap()s the remaining page.
* User process exits.
In the scenario above, the user process would cause the kernel to log
the following messages in dmesg for the first munmap(), and the second
munmap() call would result in similar log messages:
BUG: Bad page map in process doublemap.test pte:... pmd:...
page:0000000057c97bff refcount:1 mapcount:-1 \
mapping:0000000000000000 index:0x0 pfn:...
...
page dumped because: bad pte
...
file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0
...
Call Trace:
- https://git.kernel.org/stable/c/3c6a888e352283a14f37b9b433cd598a1a3a7dd0
- https://git.kernel.org/stable/c/4fb4053d90caa9985b87ec0e0c32c66a55bdfa3a
- https://git.kernel.org/stable/c/5c13a4a0291b30191eff9ead8d010e1ca43a4d0c
- https://git.kernel.org/stable/c/7c16d0a4e6a436b4e7c92bead3fab55aaa4c1141
- https://git.kernel.org/stable/c/cdafa219ace013c594e2491158ad1b51f9923dde
Modified: 2026-01-23
CVE-2022-50472
In the Linux kernel, the following vulnerability has been resolved: IB/mad: Don't call to function that might sleep while in atomic context Tracepoints are not allowed to sleep, as such the following splat is generated due to call to ib_query_pkey() in atomic context. WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220 CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:rb_commit+0xc1/0x220 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0 Call Trace: ring_buffer_unlock_commit+0x1d/0xa0 trace_buffer_unlock_commit_regs+0x3b/0x1b0 trace_event_buffer_commit+0x67/0x1d0 trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core] ib_mad_recv_done+0x48b/0xc10 [ib_core] ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core] __ib_process_cq+0x91/0x1c0 [ib_core] ib_cq_poll_work+0x26/0x80 [ib_core] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 78ba8509d3830a16 ]---
Modified: 2026-01-23
CVE-2022-50473
In the Linux kernel, the following vulnerability has been resolved: cpufreq: Init completion before kobject_init_and_add() In cpufreq_policy_alloc(), it will call uninitialed completion in cpufreq_sysfs_release() when kobject_init_and_add() fails. And that will cause a crash such as the following page fault in complete: BUG: unable to handle page fault for address: fffffffffffffff8 [..] RIP: 0010:complete+0x98/0x1f0 [..] Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
- https://git.kernel.org/stable/c/3cdd91a9163248935720927531066b74f57aa43b
- https://git.kernel.org/stable/c/5c51054896bcce1d33d39fead2af73fec24f40b6
- https://git.kernel.org/stable/c/8fb4c98f20dfca1237de2e3dfdbe78d156784fd3
- https://git.kernel.org/stable/c/d88540acfc7a17079021d866de914112c396edb1
- https://git.kernel.org/stable/c/e379b88a8f8cffc99b318e028705ed9e3da0e1e0
- https://git.kernel.org/stable/c/e7c0c943ed675b66d4bbb16c51c6a3bb58da047e
Modified: 2026-01-23
CVE-2022-50474
In the Linux kernel, the following vulnerability has been resolved: macintosh: fix possible memory leak in macio_add_one_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically. It needs to be freed when of_device_register() fails. Call put_device() to give up the reference that's taken in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hits 0. macio device is freed in macio_release_dev(), so the kfree() can be removed.
- https://git.kernel.org/stable/c/19ded60b40e86b0903c8d5bd0161437ed5107a8b
- https://git.kernel.org/stable/c/2ac0a7059b7bcbed35bfffa34a82c9a9e99638ef
- https://git.kernel.org/stable/c/35858b87a943917fa30172aa4bf01ce7adbcb42c
- https://git.kernel.org/stable/c/3a866ff6fc2232c8e393cdb55ffb8ce947349e03
- https://git.kernel.org/stable/c/5ca86eae55a2f006e6c1edd2029b2cacb6979515
- https://git.kernel.org/stable/c/76837e7f6b30da72ad59f56291e22804a219e015
- https://git.kernel.org/stable/c/aa9054267366ff0a382d403d17728e21951ddbb9
- https://git.kernel.org/stable/c/b29a2f1dd33ae9b94821ab2f4d398b9081786748
- https://git.kernel.org/stable/c/ca765257feb89dacf604ced9cd233db5f865dee0
Modified: 2026-01-23
CVE-2022-50475
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Make sure "ib_port" is valid when access sysfs node The "ib_port" structure must be set before adding the sysfs kobject, and reset after removing it, otherwise it may crash when accessing the sysfs node: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x96000006 Exception class = 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 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5 [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci] Process grep (pid: 3372, stack limit = 0x0000000022055c92) CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4c/0x80 [ib_core] lr : port_attr_show+0x40/0x58 [ib_core] sp : ffff000029f43b50 x29: ffff000029f43b50 x28: 0000000019375000 x27: ffff8007b821a540 x26: ffff000029f43e30 x25: 0000000000008000 x24: ffff000000eaa958 x23: 0000000000001000 x22: ffff8007a4ce3000 x21: ffff8007baff8000 x20: ffff8007b9066ac0 x19: ffff8007bae97578 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff8007a4ce4000 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffff000000e6a280 x4 : ffff8007a4ce3000 x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab x1 : ffff8007b9066a10 x0 : ffff8007baff8000 Call trace: hw_stat_port_show+0x4c/0x80 [ib_core] port_attr_show+0x40/0x58 [ib_core] sysfs_kf_seq_show+0x8c/0x150 kernfs_seq_show+0x44/0x50 seq_read+0x1b4/0x45c kernfs_fop_read+0x148/0x1d8 __vfs_read+0x58/0x180 vfs_read+0x94/0x154 ksys_read+0x68/0xd8 __arm64_sys_read+0x28/0x34 el0_svc_common+0x88/0x18c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861)
Modified: 2026-01-23
CVE-2022-50476
In the Linux kernel, the following vulnerability has been resolved: ntb_netdev: Use dev_kfree_skb_any() in interrupt context TX/RX callback handlers (ntb_netdev_tx_handler(), ntb_netdev_rx_handler()) can be called in interrupt context via the DMA framework when the respective DMA operations have completed. As such, any calls by these routines to free skb's, should use the interrupt context safe dev_kfree_skb_any() function. Previously, these callback handlers would call the interrupt unsafe version of dev_kfree_skb(). This has not presented an issue on Intel IOAT DMA engines as that driver utilizes tasklets rather than a hard interrupt handler, like the AMD PTDMA DMA driver. On AMD systems, a kernel WARNING message is encountered, which is being issued from skb_release_head_state() due to in_hardirq() being true. Besides the user visible WARNING from the kernel, the other symptom of this bug was that TCP/IP performance across the ntb_netdev interface was very poor, i.e. approximately an order of magnitude below what was expected. With the repair to use dev_kfree_skb_any(), kernel WARNINGs from skb_release_head_state() ceased and TCP/IP performance, as measured by iperf, was on par with expected results, approximately 20 Gb/s on AMD Milan based server. Note that this performance is comparable with Intel based servers.
- https://git.kernel.org/stable/c/07e28a8f450217db679802ebd4de0915556ce846
- https://git.kernel.org/stable/c/13286ad1c7c49c606fdcba4cf66f953a1a16c1ca
- https://git.kernel.org/stable/c/14d245da57a11e80277ab455aa9b6dcc5ed38a19
- https://git.kernel.org/stable/c/21296a52caa6a6bad6debdfe40ad81d4f1a27e69
- https://git.kernel.org/stable/c/5f7d78b2b12a9d561f48fa00bab29b40f4616dad
- https://git.kernel.org/stable/c/8b78493968ed3cef0326183ed059c55e42f24d5b
- https://git.kernel.org/stable/c/a6b9e09403102bdf8402dae734800e4916c7ea58
- https://git.kernel.org/stable/c/d4460c82177899751975180c268f352893302221
- https://git.kernel.org/stable/c/dd860b39aa7c7b82e6c99b6fdb99d4610ce49d67
Modified: 2026-01-23
CVE-2022-50478
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()
Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount
time".
The first patch fixes a bug reported by syzbot, and the second one fixes
the remaining bug of the same kind. Although they are triggered by the
same super block data anomaly, I divided it into the above two because the
details of the issues and how to fix it are different.
Both are required to eliminate the shift-out-of-bounds issues at mount
time.
This patch (of 2):
If the block size exponent information written in an on-disk superblock is
corrupted, nilfs_sb2_bad_offset helper function can trigger
shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn
is set):
shift exponent 38983 is too large for 64-bit type 'unsigned long long'
Call Trace:
- https://git.kernel.org/stable/c/1012ff77284e3bec0ec0a35a820b03ec43dec2cc
- https://git.kernel.org/stable/c/610a2a3d7d8be3537458a378ec69396a76c385b6
- https://git.kernel.org/stable/c/62d11ec205ef14d8acf172cfc9904fdbf200025a
- https://git.kernel.org/stable/c/6b0ea3df56cccd53398d0289f399f19d43136b2e
- https://git.kernel.org/stable/c/9b3ba54025357440d6c4414c670984f628c6f6bf
- https://git.kernel.org/stable/c/a6f89b10042baca218c8598d6db5a44c7e32625f
- https://git.kernel.org/stable/c/b47f5c579c8186f7f5ab5e4254e0734ea5b7bf7a
- https://git.kernel.org/stable/c/d464b035c0613856d012cf1704879d3ff3f057fb
- https://git.kernel.org/stable/c/d706485dffbbbf848e681edda29c7a46ac55698c
Modified: 2026-01-23
CVE-2022-50480
In the Linux kernel, the following vulnerability has been resolved: memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe() The break of for_each_available_child_of_node() needs a corresponding of_node_put() when the reference 'child' is not used anymore. Here we do not need to call of_node_put() in fail path as '!match' means no break. While the of_platform_device_create() will created a new reference by 'child' but it has considered the refcounting.
- https://git.kernel.org/stable/c/44db35ceb94756ba513dcf6b69bf9e949b28469c
- https://git.kernel.org/stable/c/49605dc25e7fb33bf8b671279d4468531da90f89
- https://git.kernel.org/stable/c/566b143aa5112a0c2784e20603778518bb799537
- https://git.kernel.org/stable/c/61b3c876c1cbdb1efd1f52a1f348580e6e14efb6
- https://git.kernel.org/stable/c/b37f4a711e5d4bf3608ccbc6de82b52e92b441a0
- https://git.kernel.org/stable/c/fde46754d5483bc398018bbec3c8ef5c55219e67
Modified: 2026-01-23
CVE-2022-50481
In the Linux kernel, the following vulnerability has been resolved: cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter() If device_register() fails in cxl_register_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails.
- https://git.kernel.org/stable/c/170e8c2d2b61e15e7f7cfeded81bc1e959a15ed8
- https://git.kernel.org/stable/c/1ae581696b7a799afa39a664c4b721569643f58a
- https://git.kernel.org/stable/c/60b2ed21a65f3f5318666ccd765c3507991370cf
- https://git.kernel.org/stable/c/61c80d1c3833e196256fb060382db94f24d3d9a7
- https://git.kernel.org/stable/c/96fba6fb95bdede80583c262ac185da09661f264
- https://git.kernel.org/stable/c/ab44c182353be101c3be9465e1d15d42130c53c4
- https://git.kernel.org/stable/c/b32559ee4e6667c5c3daf4ec5454c277d1f255d2
- https://git.kernel.org/stable/c/d775a1da5a52b4f4bb02f2707ba420d1bec48dbb
- https://git.kernel.org/stable/c/e5021bbf11b024cc65ea1e84c377df484183be4b
Modified: 2026-01-23
CVE-2022-50482
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clean up si_domain in the init_dmars() error path A splat from kmem_cache_destroy() was seen with a kernel prior to commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool") when there was a failure in init_dmars(), because the iommu_domain cache still had objects. While the mempool code is now gone, there still is a leak of the si_domain memory if init_dmars() fails. So clean up si_domain in the init_dmars() error path.
- https://git.kernel.org/stable/c/0365d6af75f9f2696e94a0fef24a2c8464c037c8
- https://git.kernel.org/stable/c/5cecfe151874b835331efe086bbdcaeaf64f6b90
- https://git.kernel.org/stable/c/620bf9f981365c18cc2766c53d92bf8131c63f32
- https://git.kernel.org/stable/c/724483b585a1b1e063d42ac5aa835707ff2ec165
- https://git.kernel.org/stable/c/749bea542b67513e99240dc58bbfc099e842d508
- https://git.kernel.org/stable/c/c4ad3ae4c6be9d8b0701761c839771116bca6ea3
- https://git.kernel.org/stable/c/d74196bb278b8f8af88e16bd595997dfa3d6fdb0
Modified: 2026-01-23
CVE-2022-50483
In the Linux kernel, the following vulnerability has been resolved: net: enetc: avoid buffer leaks on xdp_do_redirect() failure Before enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software BD in the RX ring between index orig_i and i can have one of 2 refcount values on its page. We are the owner of the current buffer that is being processed, so the refcount will be at least 1. If the current owner of the buffer at the diametrically opposed index in the RX ring (i.o.w, the other half of this page) has not yet called kfree(), this page's refcount could even be 2. enetc_page_reusable() in enetc_flip_rx_buff() tests for the page refcount against 1, and [ if it's 2 ] does not attempt to reuse it. But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call, the page refcount can have one of 3 values. It can also be 0, if there is no owner of the other page half, and xdp_do_redirect() for this buffer ran so far that it triggered a flush of the devmap/cpumap bulk queue, and the consumers of those bulk queues also freed the buffer, all by the time xdp_do_redirect() returns the execution back to enetc. This is the reason why enetc_flip_rx_buff() is called before xdp_do_redirect(), but there is a big flaw with that reasoning: enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the enetc_page_reusable() branch, and if xdp_do_redirect() returns an error, we call enetc_xdp_free(), which does not deal gracefully with that. In fact, what happens is quite special. The page refcounts start as 1. enetc_flip_rx_buff() figures they're reusable, transfers these rx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and bumps the refcount to 2. When xdp_do_redirect() later returns an error, we call the no-op enetc_xdp_free(), but we still haven't lost the reference to that page. A copy of it is still at rx_ring->next_to_alloc, but that has refcount 2 (and there are no concurrent owners of it in flight, to drop the refcount). What really kills the system is when we'll flip the rx_swbd->page the second time around. With an updated refcount of 2, the page will not be reusable and we'll really leak it. Then enetc_new_page() will have to allocate more pages, which will then eventually leak again on further errors from xdp_do_redirect(). The problem, summarized, is that we zeroize rx_swbd->page before we're completely done with it, and this makes it impossible for the error path to do something with it. Since the packet is potentially multi-buffer and therefore the rx_swbd->page is potentially an array, manual passing of the old pointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bit difficult. For the sake of going with a simple solution, we accept the possibility of racing with xdp_do_redirect(), and we move the flip procedure to execute only on the redirect success path. By racing, I mean that the page may be deemed as not reusable by enetc (having a refcount of 0), but there will be no leak in that case, either. Once we accept that, we have something better to do with buffers on XDP_REDIRECT failure. Since we haven't performed half-page flipping yet, we won't, either (and this way, we can avoid enetc_xdp_free() completely, which gives the entire page to the slab allocator). Instead, we'll call enetc_xdp_drop(), which will recycle this half of the buffer back to the RX ring.
Modified: 2026-01-23
CVE-2022-50484
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential memory leaks When the driver hits -ENOMEM at allocating a URB or a buffer, it aborts and goes to the error path that releases the all previously allocated resources. However, when -ENOMEM hits at the middle of the sync EP URB allocation loop, the partially allocated URBs might be left without released, because ep->nurbs is still zero at that point. Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB list.
- https://git.kernel.org/stable/c/0604e5e5537af099ea2f6dfd892afe5c92db8a80
- https://git.kernel.org/stable/c/0672215994e2347a9b4f145e2bc1709b1e01cee3
- https://git.kernel.org/stable/c/28d8d267af5d73f91d7640cbdb4024703256e36c
- https://git.kernel.org/stable/c/46f0aed47673e275d682af60ed26dcc28add8eae
- https://git.kernel.org/stable/c/6382da0828995af87aa8b8bef28cc61aceb4aff3
- https://git.kernel.org/stable/c/988ec0cd0a2643c25c1658f7c33de2e15a5a2e31
- https://git.kernel.org/stable/c/bc1d16d282bca421c6fc31de4b8fd412010f01bd
- https://git.kernel.org/stable/c/e4442410f76d66b9f7e854010bce04853f665324
- https://git.kernel.org/stable/c/faa8c1ed77d0169955b9b3516b714cc5fb512f27
Modified: 2026-03-25
CVE-2022-50485
In the Linux kernel, the following vulnerability has been resolved: ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode There are many places that will get unhappy (and crash) when ext4_iget() returns a bad inode. However, if iget the boot loader inode, allows a bad inode to be returned, because the inode may not be initialized. This mechanism can be used to bypass some checks and cause panic. To solve this problem, we add a special iget flag EXT4_IGET_BAD. Only with this flag we'd be returning bad inode from ext4_iget(), otherwise we always return the error code if the inode is bad inode.(suggested by Jan Kara)
- https://git.kernel.org/stable/c/2142dfa1de61e25b83198af0308ec7689cca25d3
- https://git.kernel.org/stable/c/488a5c2bf7543c3cd3f07a025f2e62be91599430
- https://git.kernel.org/stable/c/63b1e9bccb71fe7d7e3ddc9877dbdc85e5d2d023
- https://git.kernel.org/stable/c/c0a738875c2e9c8c3366d792f8bf7fe508d5e5a5
- https://git.kernel.org/stable/c/f725b290ed79ad61e4f721fee95a287892d8b1ad
- https://git.kernel.org/stable/c/f7e6b5548f915d7aa435d0764d41eacfb49c6e09
Modified: 2026-03-25
CVE-2022-50486
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: Fix return type of netcp_ndo_start_xmit() With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/net/ethernet/ti/netcp_core.c:1944:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netcp_ndo_start_xmit, ^~~~~~~~~~~~~~~~~~~~ 1 error generated. ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of netcp_ndo_start_xmit() to match the prototype's to resolve the warning and CFI failure.
- https://git.kernel.org/stable/c/17bb9bdf701f3e811a9f4820b08b9538ade2641c
- https://git.kernel.org/stable/c/1e4953b826e12b31995564a459dbd4e9e4604a35
- https://git.kernel.org/stable/c/5b0b6553bf4ad3a435a57e02c68d6075f384e1be
- https://git.kernel.org/stable/c/63fe6ff674a96cfcfc0fa8df1051a27aa31c70b4
- https://git.kernel.org/stable/c/765636e58ba505cfe4927eda7ee83791b1c6402a
- https://git.kernel.org/stable/c/a413ebb6049edd881c6427cfa25a7efddd6a4f74
- https://git.kernel.org/stable/c/a447479ea2cf35603b5739ea947885024b901222
- https://git.kernel.org/stable/c/d837d74eae077cc3ef9e191ba8535b5f602d4673
- https://git.kernel.org/stable/c/dbe1a6b930ae9647e8ce0b684c903ac67d4398eb
Modified: 2026-03-25
CVE-2022-50488
In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10: ================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace: bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0 __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0 __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90 __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups") changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | Λ | Λ | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | Λ | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) Λ |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic.
- https://git.kernel.org/stable/c/094f3d9314d67691cb21ba091c1b528f6e3c4893
- https://git.kernel.org/stable/c/5533742c7cb1bc9b1f0bf401cc397d44a3a9e07a
- https://git.kernel.org/stable/c/64dc8c732f5c2b406cc752e6aaa1bd5471159cab
- https://git.kernel.org/stable/c/761564d93c8265f65543acf0a576b32d66bfa26a
- https://git.kernel.org/stable/c/b22fd72bfebda3956efc4431b60ddfc0a51e03e0
Modified: 2026-03-25
CVE-2022-50489
In the Linux kernel, the following vulnerability has been resolved: drm/mipi-dsi: Detach devices when removing the host Whenever the MIPI-DSI host is unregistered, the code of mipi_dsi_host_unregister() loops over every device currently found on that bus and will unregister it. However, it doesn't detach it from the bus first, which leads to all kind of resource leaks if the host wants to perform some clean up whenever a device is detached.
- https://git.kernel.org/stable/c/262364574b05676d4b9ebde2ddd3588cd2efd8ce
- https://git.kernel.org/stable/c/26c1b4cfe56f040f71a51c92da1f4cac2e3b9455
- https://git.kernel.org/stable/c/353ab1c13fdd6e524edde780235a8ce9b892c81c
- https://git.kernel.org/stable/c/45120fa5e522d444e3fc1c5a9afc5d53eed91d00
- https://git.kernel.org/stable/c/668a8f17b5290d04ef7343636a5588a0692731a1
- https://git.kernel.org/stable/c/6fc2cd40db1969ba372ce9536dcfcdb87271eac4
- https://git.kernel.org/stable/c/8242167cfc83dd7e4c96f44b45f108db9bb88146
- https://git.kernel.org/stable/c/95ae458209f5a556bba98aff872f933694914eb7
- https://git.kernel.org/stable/c/c202cda08cd5693645d4990ad1eb2e8068a884ec
Modified: 2026-03-25
CVE-2022-50490
In the Linux kernel, the following vulnerability has been resolved: bpf: Propagate error from htab_lock_bucket() to userspace In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns -EBUSY, it will go to next bucket. Going to next bucket may not only skip the elements in current bucket silently, but also incur out-of-bound memory access or expose kernel memory to userspace if current bucket_cnt is greater than bucket_size or zero. Fixing it by stopping batch operation and returning -EBUSY when htab_lock_bucket() fails, and the application can retry or skip the busy batch as needed.
Modified: 2026-03-25
CVE-2022-50491
In the Linux kernel, the following vulnerability has been resolved:
coresight: cti: Fix hang in cti_disable_hw()
cti_enable_hw() and cti_disable_hw() are called from an atomic context
so shouldn't use runtime PM because it can result in a sleep when
communicating with firmware.
Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock
management to the SCMI power domain""), this causes a hang on Juno when
running the Perf Coresight tests or running this command:
perf record -e cs_etm//u -- ls
This was also missed until the revert commit because pm_runtime_put()
was called with the wrong device until commit 692c9a499b28 ("coresight:
cti: Correct the parameter for pm_runtime_put")
With lock and scheduler debugging enabled the following is output:
coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti
BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<0000000000000000>] 0x0
hardirqs last disabled at (0): [
Modified: 2026-01-23
CVE-2022-50493
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash when I/O abort times out While performing CPU hotplug, a crash with the following stack was seen: Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0 On abort timeout, completion was called without checking if the I/O was already completed. Verify that I/O and abort request are indeed outstanding before attempting completion.
Modified: 2026-01-23
CVE-2022-50494
In the Linux kernel, the following vulnerability has been resolved:
thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash
When CPU 0 is offline and intel_powerclamp is used to inject
idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687
caller is debug_smp_processor_id+0x17/0x20
CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57
Call Trace:
- https://git.kernel.org/stable/c/0f91f66c568b316b19cb042cf50584467b3bdff4
- https://git.kernel.org/stable/c/3e799e815097febbcb81b472285be824f5d089f9
- https://git.kernel.org/stable/c/418fae0700e85a498062424f8656435c32cdb200
- https://git.kernel.org/stable/c/513943bf879d45005213e6f5cfb7d9e9943f589f
- https://git.kernel.org/stable/c/5614908434451aafbf9b24cb5247cf1d21269f76
- https://git.kernel.org/stable/c/5a646c38f648185ee2c62f2a19da3c6f04e27612
- https://git.kernel.org/stable/c/68b99e94a4a2db6ba9b31fe0485e057b9354a640
- https://git.kernel.org/stable/c/6904727db0eb62fb0c2dce1cf331c341d97ee4b7
- https://git.kernel.org/stable/c/6e2a347b304224b2aeb1c0ea000d1cf8a02cc592
Modified: 2026-01-22
CVE-2022-50496
In the Linux kernel, the following vulnerability has been resolved: dm cache: Fix UAF in destroy() Dm_cache also has the same UAF problem when dm_resume() and dm_destroy() are concurrent. Therefore, cancelling timer again in destroy().
- https://git.kernel.org/stable/c/034cbc8d3b47a56acd89453c29632a9c117de09d
- https://git.kernel.org/stable/c/2b17026685a270b2beaf1cdd9857fcedd3505c7e
- https://git.kernel.org/stable/c/2f097dfac7579fd84ff98eb1d3acd41d53a485f3
- https://git.kernel.org/stable/c/4d20032dd90664de09f2902a7ea49ae2f7771746
- https://git.kernel.org/stable/c/6a3e412c2ab131c54945327a7676b006f000a209
- https://git.kernel.org/stable/c/6a459d8edbdbe7b24db42a5a9f21e6aa9e00c2aa
- https://git.kernel.org/stable/c/6ac4f36910764cb510bafc4c3768544f86ca48ca
- https://git.kernel.org/stable/c/993406104d2b28fe470126a062ad37a1e21e792e
- https://git.kernel.org/stable/c/d2a0b298ebf83ab6236f66788a3541e91ce75a70
Modified: 2026-01-22
CVE-2022-50497
In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: fix shift-out-of-bounds in check_special_flags
UBSAN reported a shift-out-of-bounds warning:
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/0f1a48994b3e516d5c7fd5d12204fdba7a604771
- https://git.kernel.org/stable/c/419b808504c26b3e3342365f34ccd0843e09a7f8
- https://git.kernel.org/stable/c/6a46bf558803dd2b959ca7435a5c143efe837217
- https://git.kernel.org/stable/c/88cea1676a09f7c45a1438153a126610c33b1590
- https://git.kernel.org/stable/c/97382a2639b1cd9631f6069061e9d7062cd2b098
- https://git.kernel.org/stable/c/a651bb5ff997b9f02662bcdef3d8b4e6f0d79656
- https://git.kernel.org/stable/c/a91123d4bda463469f68f0427adabf8108001f94
- https://git.kernel.org/stable/c/dcbc51d31d0afbd45e830e3cf565a7b3ca7bf0d8
- https://git.kernel.org/stable/c/ea6145370be8016755c43aca799815fc4b8c88b1
Modified: 2026-01-22
CVE-2022-50498
In the Linux kernel, the following vulnerability has been resolved:
eth: alx: take rtnl_lock on resume
Zbynek reports that alx trips an rtnl assertion on resume:
RTNL: assertion failed at net/core/dev.c (2891)
RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0
Call Trace:
Modified: 2026-01-22
CVE-2022-50499
In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: Fix double free in dvb_register_device() In function dvb_register_device() -> dvb_register_media_device() -> dvb_create_media_entity(), dvb->entity is allocated and initialized. If the initialization fails, it frees the dvb->entity, and return an error code. The caller takes the error code and handles the error by calling dvb_media_device_free(), which unregisters the entity and frees the field again if it is not NULL. As dvb->entity may not NULLed in dvb_create_media_entity() when the allocation of dvbdev->pad fails, a double free may occur. This may also cause an Use After free in media_device_unregister_entity(). Fix this by storing NULL to dvb->entity when it is freed.
- https://git.kernel.org/stable/c/0588b12c418c3e4f927ced11f27b02ef4a5bfb07
- https://git.kernel.org/stable/c/123eddf92a114e03919942641d2c2b1f4ca56ea6
- https://git.kernel.org/stable/c/6b0d0477fce747d4137aa65856318b55fba72198
- https://git.kernel.org/stable/c/70bc51303871159796b55ba1a8f16637b46c2511
- https://git.kernel.org/stable/c/772892b29ac50c2c5e918fc80104aa6ede81d837
- https://git.kernel.org/stable/c/7dd5a68cdbbbe7fc67ba701cb52ba10d8ba149f8
- https://git.kernel.org/stable/c/acf984a3718c2458eb9e08b6714490a04f213c58
- https://git.kernel.org/stable/c/b21f62b49ee9c3e0216d685d9cfd6003e5727271
- https://git.kernel.org/stable/c/e9a78485b658361fab6a5547377be6c1af6f1b3d
Modified: 2026-01-22
CVE-2022-50501
In the Linux kernel, the following vulnerability has been resolved: media: coda: Add check for dcoda_iram_alloc As the coda_iram_alloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others.
- https://git.kernel.org/stable/c/05f165ded4a7baec31b65aba88e2cd1fb9b91db2
- https://git.kernel.org/stable/c/2b436f1410245412ea5e4c356a175a928d73eed3
- https://git.kernel.org/stable/c/2c6887d5a29024bada6928d1d0959c9990401384
- https://git.kernel.org/stable/c/35ddd00b36589cf948875b825eedaab1aefd5ad5
- https://git.kernel.org/stable/c/45f57abaee136a1e39d2b04443a1bd5311ba7d94
- https://git.kernel.org/stable/c/532417dc98cb9c1185ada4ea4e7ccf965c06bcb5
- https://git.kernel.org/stable/c/5688d33aa293dfa122d66bef9c0258ddf7ef11e7
- https://git.kernel.org/stable/c/6b8082238fb8bb20f67e46388123e67a5bbc558d
- https://git.kernel.org/stable/c/b99872178e7473f21904fdeea38109275aad8ae8
Modified: 2026-01-22
CVE-2022-50503
In the Linux kernel, the following vulnerability has been resolved: mtd: lpddr2_nvm: Fix possible null-ptr-deref It will cause null-ptr-deref when resource_size(add_range) invoked, if platform_get_resource() returns NULL.
- https://git.kernel.org/stable/c/0919982a1744346269320615615c7deb14106661
- https://git.kernel.org/stable/c/4d10bd7416e8383340b5524b8d616b8ad01ef1e1
- https://git.kernel.org/stable/c/6bdd45d795adf9e73b38ced5e7f750cd199499ff
- https://git.kernel.org/stable/c/8eb64dc5a790a529ef49ec94b3337af09dac15d3
- https://git.kernel.org/stable/c/bb9ccb6121ec4140d366147aa866ceb5a21a8d3d
- https://git.kernel.org/stable/c/c4cc41e94d8357f5f02b8ef40257bb23931d8438
- https://git.kernel.org/stable/c/e0d3e46ac6669cdf1b99bc7b7d92f1221b9a1ff2
- https://git.kernel.org/stable/c/e6aafb57d90ff2c1e18554f3a3c36247a59825ce
- https://git.kernel.org/stable/c/f82f63b3911f1b2da68a14d9c4babf3b55feca55
Modified: 2026-01-22
CVE-2022-50504
In the Linux kernel, the following vulnerability has been resolved: powerpc/rtas: avoid scheduling in rtas_os_term() It's unsafe to use rtas_busy_delay() to handle a busy status from the ibm,os-term RTAS function in rtas_os_term(): Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9 Call Trace: [c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable) [c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0 [c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0 [c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4 [c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68 [c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50 [c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0 [c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0 [c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0 [c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420 [c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200 Use rtas_busy_delay_time() instead, which signals without side effects whether to attempt the ibm,os-term RTAS call again.
- https://git.kernel.org/stable/c/4768935b8cc2d2afeb7956292df0f6e2c49ca0a5
- https://git.kernel.org/stable/c/482d990a5dd1027ee0b70a8a570d56749cac8103
- https://git.kernel.org/stable/c/515959eb49e6d218a46979d66f36fdef329ac7d2
- https://git.kernel.org/stable/c/6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4
- https://git.kernel.org/stable/c/6f7e2fcab73372a371ab4017cbedf7a71f4f9b40
- https://git.kernel.org/stable/c/7280fdb80bf0fe35d9b799fc7009f2cbe0a397d7
- https://git.kernel.org/stable/c/bed48651c87bef59ea1a9d6dbc381bcbc452f4ff
- https://git.kernel.org/stable/c/f413135b337c4e90c1e593c6613f8717e17bc724
- https://git.kernel.org/stable/c/ffa991a003abb4f8cb9e5004646bfe2d9a46912c
Modified: 2026-03-25
CVE-2022-50505
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix pci device refcount leak in ppr_notifier() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it before returning from ppr_notifier() to avoid refcount leak.
- https://git.kernel.org/stable/c/03f51c72997559e73b327608f0cccfded715c9a0
- https://git.kernel.org/stable/c/6cf0981c2233f97d56938d9d61845383d6eb227c
- https://git.kernel.org/stable/c/6e501b3fd7a2e1c4372d72bc70717aaca2beb8a5
- https://git.kernel.org/stable/c/8581ec1feb895ff596fe3d326d9ba320083290aa
- https://git.kernel.org/stable/c/902cc2507091a81643502d8ceb0e2f105e902518
- https://git.kernel.org/stable/c/b0637f4bd426925f5c3a15e8f8e36190fe06bac5
- https://git.kernel.org/stable/c/bdb2113dd8f17a3cc84a2b4be4968a849f69ec72
- https://git.kernel.org/stable/c/efd50c65fd1cdef63eb58825f3fe72496443764c
Modified: 2026-03-25
CVE-2022-50507
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate data run offset
This adds sanity checks for data run offset. We should make sure data
run offset is legit before trying to unpack them, otherwise we may
encounter use-after-free or some unexpected memory access behaviors.
[ 82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570
[ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240
[ 82.941670]
[ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15
[ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 82.943720] Call Trace:
[ 82.944204]
Modified: 2026-03-17
CVE-2022-50509
In the Linux kernel, the following vulnerability has been resolved: media: coda: Add check for kmalloc As the kmalloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others.
- https://git.kernel.org/stable/c/0209e70ad496c1fcd85c2ec70e6736fd09f95d14
- https://git.kernel.org/stable/c/11e32126b3e56c3156fb610d793732acd2bdac4f
- https://git.kernel.org/stable/c/441c05485cf1a29eef05c1fd8281716815283315
- https://git.kernel.org/stable/c/6e5e5defdb8b0186312c2f855ace175aee6daf9b
- https://git.kernel.org/stable/c/7a2c66429b04e85fee44d6d9f455327bf23cf49c
- https://git.kernel.org/stable/c/aa17a252dbde432095e390e2092205d4debb12e1
- https://git.kernel.org/stable/c/ba9cc9e2035f7a45f5222543265daf7cd51f2530
- https://git.kernel.org/stable/c/d308c4a035b636756786af91e5f39f9d92d7d42a
- https://git.kernel.org/stable/c/d9b37ea8869e4e6da90c07a310d819a78cbd23d2
Modified: 2026-03-17
CVE-2022-50510
In the Linux kernel, the following vulnerability has been resolved: perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init() arm_smmu_pmu_init() won't remove the callback added by cpuhp_setup_state_multi() when platform_driver_register() failed. Remove the callback by cpuhp_remove_multi_state() in fail path. Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus: arm-ccn: Prevent hotplug callback leak")
- https://git.kernel.org/stable/c/359286f886feef38536eaa7e673dc3440f03b0a1
- https://git.kernel.org/stable/c/582babe17ea878ec1d76f30e03f3a6ce6e30eb91
- https://git.kernel.org/stable/c/6f2d566b46436a50a80d6445e82879686b89588c
- https://git.kernel.org/stable/c/b131304fe722853cf26e55c4fa21fc58a36e7f21
- https://git.kernel.org/stable/c/d69bdb61d577297d3851fc9f6403574bf73ef41f
- https://git.kernel.org/stable/c/f245ca9a0fe7f794a8187ad803d5e2ced5a11cb2
Modified: 2026-03-17
CVE-2022-50511
In the Linux kernel, the following vulnerability has been resolved:
lib/fonts: fix undefined behavior in bit shift for get_default_font
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20
left shift of 1 by 31 places cannot be represented in type 'int'
- https://git.kernel.org/stable/c/6fe888c4d2fb174408e4540bb2d5602b9f507f90
- https://git.kernel.org/stable/c/890d91b31f4874361e0df047f57d268a7021cb12
- https://git.kernel.org/stable/c/9c14a85e18a58c102ec223144b7edb5b345c1bea
- https://git.kernel.org/stable/c/c9a9aa02f0fa3318e0ae5774f404419a1b4759ca
- https://git.kernel.org/stable/c/e039929e36818507e90901edae87f6fa8bc81093
- https://git.kernel.org/stable/c/e83b47580a0738361772d6f24286adfdaba57e36
Modified: 2026-03-17
CVE-2022-50512
In the Linux kernel, the following vulnerability has been resolved: ext4: fix potential memory leak in ext4_fc_record_regions() As krealloc may return NULL, in this case 'state->fc_regions' may not be freed by krealloc, but 'state->fc_regions' already set NULL. Then will lead to 'state->fc_regions' memory leak.
- https://git.kernel.org/stable/c/2cfb769d60a2a57eb3566765428b6131cd16dcfe
- https://git.kernel.org/stable/c/417b0455a0b6d0f60a2930592731d1f8340e24be
- https://git.kernel.org/stable/c/518566e71ad86b7c2f1bf6d9caee9588bb7ac158
- https://git.kernel.org/stable/c/7069d105c1f15c442b68af43f7fde784f3126739
- https://git.kernel.org/stable/c/a4058b869e6c5e517c79e30532a350d0f3115c3e
Modified: 2026-03-17
CVE-2022-50513
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv() In rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocated in failure, then `pcmdpriv->cmd_allocated_buf` will be not properly released. Besides, considering there are only two error paths and the first one can directly return, so we do not need implicitly jump to the `exit` tag to execute the error handler. So this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the error path to release the resource and simplified the return logic of rtw_init_cmd_priv(). As there is no proper device to test with, no runtime testing was performed.
- https://git.kernel.org/stable/c/39bef9c6a91bbb790d04c1347cfeae584541fb6a
- https://git.kernel.org/stable/c/708056fba733a73d926772ea4ce9a42d240345da
- https://git.kernel.org/stable/c/8db6ca84eee0ac258706f3fca54f7c021cb159ef
- https://git.kernel.org/stable/c/a5be64ff6d21f7805a91e6d81f53fc19cd9f0fae
- https://git.kernel.org/stable/c/e5d8f05edb36fc4ab15beec62cb6ab62f5a60fe2
- https://git.kernel.org/stable/c/e6cc39db24a63f68314473621020ed8cad7be423
Modified: 2026-03-17
CVE-2022-50514
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: fix refcount leak on error path When failing to allocate report_desc, opts->refcnt has already been incremented so it needs to be decremented to avoid leaving the options structure permanently locked.
- https://git.kernel.org/stable/c/216437dd64fce36791a3b6cc8f8013df36856958
- https://git.kernel.org/stable/c/70a3288a7586526315105c699b687d78cd32559a
- https://git.kernel.org/stable/c/80dc47e751a837106c09bec73964ff8f7ea280b4
- https://git.kernel.org/stable/c/95412c932b3c9e8cc4431dac4fac8fcd80d54982
- https://git.kernel.org/stable/c/9d4a0aca8a75550d3456c8de339a341dc4536ec5
- https://git.kernel.org/stable/c/ba78f7c10606719f702c04a15fb0471507b32d7b
- https://git.kernel.org/stable/c/e88b89a096af0001bcff6bf7ad2feb1486487173
Modified: 2026-03-17
CVE-2022-50515
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix memory leak in hpd_rx_irq_create_workqueue() If construction of the array of work queues to handle hpd_rx_irq offload work fails, we need to unwind. Destroy all the created workqueues and the allocated memory for the hpd_rx_irq_offload_work_queue struct array.
Modified: 2026-03-17
CVE-2022-50516
In the Linux kernel, the following vulnerability has been resolved:
fs: dlm: fix invalid derefence of sb_lvbptr
I experience issues when putting a lkbsb on the stack and have sb_lvbptr
field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash
with the following kernel message, the dangled pointer is here
0xdeadbeef as example:
[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef
[ 102.749320] #PF: supervisor read access in kernel mode
[ 102.749323] #PF: error_code(0x0000) - not-present page
[ 102.749325] PGD 0 P4D 0
[ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI
[ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565
[ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014
[ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10
[ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1
- https://git.kernel.org/stable/c/1ab6d3030652b5de0015176a5b0ad9df9b847514
- https://git.kernel.org/stable/c/57c1cfb5781068e5d3632bc6e5f74a8fcc4f1a30
- https://git.kernel.org/stable/c/7175e131ebba47afef47e6ac4d5bab474d1e6e49
- https://git.kernel.org/stable/c/ea7be82fd7e1f5de72208bce93fbbe6de6c13dec
- https://git.kernel.org/stable/c/ef3033b435a6bac547166b793025578fab2f9df3
Modified: 2026-03-17
CVE-2022-50519
In the Linux kernel, the following vulnerability has been resolved: nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure If creation or finalization of a checkpoint fails due to anomalies in the checkpoint metadata on disk, a kernel warning is generated. This patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted with panic_on_warn, does not panic. A nilfs_error is appropriate here to handle the abnormal filesystem condition. This also replaces the detected error codes with an I/O error so that neither of the internal error codes is returned to callers.
- https://git.kernel.org/stable/c/090fcfb6edeb9367a915b2749e2bd1f8b48d8898
- https://git.kernel.org/stable/c/259c0f68168ac6a598db3486597b10e74d625db0
- https://git.kernel.org/stable/c/5c0776b5bc31de7cd28afb558fae37a20f33602e
- https://git.kernel.org/stable/c/723ac751208f6d6540191689cfbf6c77135a7a1b
- https://git.kernel.org/stable/c/8a18fdc5ae8e6d7ac33c6ee0a2e5f9f1414ef412
- https://git.kernel.org/stable/c/ae16440c44ae2acda6d72aff9d74eccf8967dae5
- https://git.kernel.org/stable/c/b63026b5e13040cd5afa11769dd0d9e1504b031a
- https://git.kernel.org/stable/c/bf98be80cbe3b4e6c86c36ed00457389aca3eb15
- https://git.kernel.org/stable/c/c0c3d3d3ea41cb5228ee90568bb953f9a56c3227
Modified: 2026-03-17
CVE-2022-50520
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios() As comment of pci_get_class() says, it returns a pci_device with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL. If we break the loop in radeon_atrm_get_bios() with 'pdev' not NULL, we need to call pci_dev_put() to decrease the refcount. Add the missing pci_dev_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1079df6acf56f99d86b0081a38c84701412cc90e
- https://git.kernel.org/stable/c/3991d98a8a07b71c02f3a39f77d6d9a7f575a5c4
- https://git.kernel.org/stable/c/470a77989037c3ab2b08bf2d026d2c0ddc35ff5b
- https://git.kernel.org/stable/c/6f28c7f67af4ef9bca580ab67ae2d4511797af56
- https://git.kernel.org/stable/c/725a521a18734f65de05b8d353b5bd0d3ca4c37a
- https://git.kernel.org/stable/c/88c6e0995c04b170563b5c894c50a3b2152e18c2
- https://git.kernel.org/stable/c/a6cffe54064a5f6c2162a85af3c16c6b453eac4e
- https://git.kernel.org/stable/c/b9decada8749b606fd8b4f04a3d6c74f7983d7bc
- https://git.kernel.org/stable/c/e738f82e5b1311e8fb3d1409491a6fcce6418fbe
Modified: 2026-03-17
CVE-2022-50521
In the Linux kernel, the following vulnerability has been resolved: platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]() The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method() is not freed after the call, so it leads to memory leak. The method results in ACPI buffer is not used, so just pass NULL to wmi_evaluate_method() which fixes the memory leak.
- https://git.kernel.org/stable/c/14bb4bde3b7b2584734b13747b345caeeb41bea3
- https://git.kernel.org/stable/c/17cd8c46cbec4e6ad593fb9159928b8e7608c11a
- https://git.kernel.org/stable/c/379e7794c5e7485193d25d73614fbbd1e1387f6f
- https://git.kernel.org/stable/c/3cf81501356c9e898ad94b2369ffc805f83f7d7b
- https://git.kernel.org/stable/c/50ac517d6f5348b276f1f663799cf85dce521518
- https://git.kernel.org/stable/c/5b0f81b0808235967868e01336c976e840217108
- https://git.kernel.org/stable/c/727cc0147f5066e359aca65cc6cc5e6d64cc15d8
- https://git.kernel.org/stable/c/87426ce3bd57ad414b6e2436434ef8128986a9a5
Modified: 2026-03-17
CVE-2022-50522
In the Linux kernel, the following vulnerability has been resolved: mcb: mcb-parse: fix error handing in chameleon_parse_gdd() If mcb_device_register() returns error in chameleon_parse_gdd(), the refcount of bus and device name are leaked. Fix this by calling put_device() to give up the reference, so they can be released in mcb_release_dev() and kobject_cleanup().
- https://git.kernel.org/stable/c/110dc34c9fa33d37f55b394b1199ea6c0ad1ee84
- https://git.kernel.org/stable/c/43bfc7c2402a22d3b4eb08c040f274ba2b76461a
- https://git.kernel.org/stable/c/4a9f1a8b3af287581ffb690d0e1593c681729ddb
- https://git.kernel.org/stable/c/728ac3389296caf68638628c987aeae6c8851e2d
- https://git.kernel.org/stable/c/7b289b791a59386dc23a00d3cf17a0db984b40d3
- https://git.kernel.org/stable/c/891f606ae0765bc9ca99f5276735be4d338f0255
- https://git.kernel.org/stable/c/b948baa29394ec5f4e6ec28486e7d06a76caee91
- https://git.kernel.org/stable/c/cf6e70c0ced50b52415ac0c88eba1fb09c500a5a
- https://git.kernel.org/stable/c/fd85ece416fd7edb945203e59d4cd94952f77e7c
Modified: 2026-03-17
CVE-2022-50523
In the Linux kernel, the following vulnerability has been resolved: clk: rockchip: Fix memory leak in rockchip_clk_register_pll() If clk_register() fails, @pll->rate_table may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it.
- https://git.kernel.org/stable/c/20201c3a0a32f127fa4bdf379d6ac01c2978702d
- https://git.kernel.org/stable/c/26b94635f1c84d7f6cb482179125cb17e59c90a5
- https://git.kernel.org/stable/c/5b0a1f1247cd42ac5e0d369f8dbb58762692edee
- https://git.kernel.org/stable/c/739a6a6bbdb793bd57938cb24aa5a6df89983546
- https://git.kernel.org/stable/c/86e1e080ad14c5fb6c14a5f0eb530b1b38cbc968
- https://git.kernel.org/stable/c/dcd4ba068b194c6ef0071491aa3f12bec8c14d5b
- https://git.kernel.org/stable/c/f02c1d8dc8d880cbaaf9094b4f396fe868ee23ff
- https://git.kernel.org/stable/c/f2ffb8653ea85ae39ce44347751fcc4c3e41f6bb
- https://git.kernel.org/stable/c/f4d70c139d313948e02360304a6cbcd3a4f5deb5
Modified: 2026-03-17
CVE-2022-50525
In the Linux kernel, the following vulnerability has been resolved: iommu/fsl_pamu: Fix resource leak in fsl_pamu_probe() The fsl_pamu_probe() returns directly when create_csd() failed, leaving irq and memories unreleased. Fix by jumping to error if create_csd() returns error.
- https://git.kernel.org/stable/c/0d240ac0e4c35d3f64fc782c11433138c1bd016e
- https://git.kernel.org/stable/c/17fd440594961c5e2ea0f58591bc1bdba0629c75
- https://git.kernel.org/stable/c/73f5fc5f884ad0c5f7d57f66303af64f9f002526
- https://git.kernel.org/stable/c/9238b687fd62cde14c6e2e8576a40e4246de7ebe
- https://git.kernel.org/stable/c/9fbccdf2fefa3944dd8ba8c6a808b387787f3917
- https://git.kernel.org/stable/c/a305d0e4d0ce3166e31d7dbcb4c98b09cad6d49a
- https://git.kernel.org/stable/c/c93983230562883e0b5f122040efbb3d478c36d4
- https://git.kernel.org/stable/c/de7eb55009796687fc0a1670e0b944fa8ed54e9b
- https://git.kernel.org/stable/c/e42b543d08052c3b223bcfb48f05cbaf0b767f86
Modified: 2026-03-17
CVE-2022-50528
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix memory leakage This patch fixes potential memory leakage and seg fault in _gpuvm_import_dmabuf() function
Modified: 2026-03-17
CVE-2022-50529
In the Linux kernel, the following vulnerability has been resolved:
test_firmware: fix memory leak in test_firmware_init()
When misc_register() failed in test_firmware_init(), the memory pointed
by test_fw_config->name is not released. The memory leak information is
as follows:
unreferenced object 0xffff88810a34cb00 (size 32):
comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s)
hex dump (first 32 bytes):
74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi
6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n...............
backtrace:
[
- https://git.kernel.org/stable/c/04dd47a2e169f2d4489636afa07ff0469aab49ab
- https://git.kernel.org/stable/c/0b5a89e8bce1ea43687742b4de8e216189ff94ac
- https://git.kernel.org/stable/c/357379d504c0c8b0834e206ad8c49e4b3c98ed4d
- https://git.kernel.org/stable/c/628de998a3abfffb3f9677d2fb39a1d5dcb32fdb
- https://git.kernel.org/stable/c/6dd5fbd243f19f087dc79481acb7d69fb57fea2c
- https://git.kernel.org/stable/c/7610615e8cdb3f6f5bbd9d8e7a5d8a63e3cabf2e
- https://git.kernel.org/stable/c/8d8c1d6a430f0aadb80036e2b1bc0a05f9fad247
- https://git.kernel.org/stable/c/ed5cbafaf7ce8b86f19998c00eb020c8d49b017f
Modified: 2026-03-17
CVE-2022-50531
In the Linux kernel, the following vulnerability has been resolved: tipc: fix an information leak in tipc_topsrv_kern_subscr Use a 8-byte write to initialize sub.usr_handle in tipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized when issuing setsockopt(..., SOL_TIPC, ...). This resulted in an infoleak reported by KMSAN when the packet was received: ===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169 instrument_copy_to_user ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/iov_iter.c:169 _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527 copy_to_iter ./include/linux/uio.h:176 simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419 skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527 skb_copy_datagram_msg ./include/linux/skbuff.h:3903 packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469 ____sys_recvmsg+0x2c4/0x810 net/socket.c:? ___sys_recvmsg+0x217/0x840 net/socket.c:2743 __sys_recvmsg net/socket.c:2773 __do_sys_recvmsg net/socket.c:2783 __se_sys_recvmsg net/socket.c:2780 __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 ... Uninit was stored to memory at: tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375 tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084 tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201 __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 __se_sys_setsockopt net/socket.c:2260 __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 Local variable sub created at: tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================
- https://git.kernel.org/stable/c/3d1b83ff7b6575a4e41283203e6b2e25ea700cd7
- https://git.kernel.org/stable/c/567f8de358b61015dcfb8878a1f06c5369a45f54
- https://git.kernel.org/stable/c/777ecaabd614d47c482a5c9031579e66da13989a
- https://git.kernel.org/stable/c/dbc01c0a4e202a7e925dad1d4b7c1d6eb0c81154
- https://git.kernel.org/stable/c/e558e148938442dd49628cd7ef61c360832bef31
- https://git.kernel.org/stable/c/fef70f978bc289642501d88d2a3f5e841bd31a67
Modified: 2026-03-17
CVE-2022-50532
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add() In mpt3sas_transport_port_add(), if sas_rphy_add() returns error, sas_rphy_free() needs be called to free the resource allocated in sas_end_device_alloc(). Otherwise a kernel crash will happen: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_rphy_remove+0x50/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_rphy_remove+0x38/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] scsih_remove+0xd8/0x420 [mpt3sas] Because transport_add_device() is not called when sas_rphy_add() fails, the device is not added. When sas_rphy_remove() is subsequently called to remove the device in the remove() path, a NULL pointer dereference happens.
- https://git.kernel.org/stable/c/6a92129c8f999ff5b122c100ce7f625eb3e98c4b
- https://git.kernel.org/stable/c/6f6768e2fc8638fabdd8802c2ef693d7aef01db1
- https://git.kernel.org/stable/c/78316e9dfc24906dd474630928ed1d3c562b568e
- https://git.kernel.org/stable/c/ce1a69cc85006b494353911b35171da195d79e25
- https://git.kernel.org/stable/c/d17bca3ddfe507874cb826d32721552da12e741f
- https://git.kernel.org/stable/c/d60000cb1195a464080b0efb4949daf7594e0020
Modified: 2026-03-17
CVE-2022-50534
In the Linux kernel, the following vulnerability has been resolved:
dm thin: Use last transaction's pmd->root when commit failed
Recently we found a softlock up problem in dm thin pool btree lookup
code due to corrupted metadata:
Kernel panic - not syncing: softlockup: hung tasks
CPU: 7 PID: 2669225 Comm: kworker/u16:3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Workqueue: dm-thin do_worker [dm_thin_pool]
Call Trace:
- https://git.kernel.org/stable/c/3db757ffdd87ed8d7118b2250236a496502a660f
- https://git.kernel.org/stable/c/4b710e8481ade7c9200e94d3018e99dc42a0a0e8
- https://git.kernel.org/stable/c/7991dbff6849f67e823b7cc0c15e5a90b0549b9f
- https://git.kernel.org/stable/c/87d69b8824ca9b090f5a8ed47f758e8f6eecb871
- https://git.kernel.org/stable/c/94f01ecc2aa0be992865acc80ebb6701f731f955
- https://git.kernel.org/stable/c/a63ce4eca86fd207e3db07c00fb7ccf4adf1b230
- https://git.kernel.org/stable/c/b35a22760aa5008d82533e59b0f0b5eb1b02d4e5
- https://git.kernel.org/stable/c/b91f481300e3a10eaf66b94fc39b740928762aaf
- https://git.kernel.org/stable/c/f758987ff0af3a4b5ee69e95cab6a5294e4367b0
Modified: 2026-02-26
CVE-2022-50536
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data
In tcp_bpf_send_verdict() redirection, the eval variable is assigned to
__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,
sock_put() will be called multiple times.
We should reset the eval variable to __SK_NONE every time more_data
starts.
This causes:
IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110
Modules linked in:
CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1
Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/113236e8f49f262f318c00ebb14b15f4834e87c1
- https://git.kernel.org/stable/c/28e4a763cd4a2b1a78852216ef4bd7df3a05cec6
- https://git.kernel.org/stable/c/578a7628b838a3ac8ad61deaab5a816ff032ac13
- https://git.kernel.org/stable/c/7508b9f4daac4ec7dfe0b6fb2d688b1c1c105e10
- https://git.kernel.org/stable/c/7a9841ca025275b5b0edfb0b618934abb6ceec15
- https://git.kernel.org/stable/c/8786bde11a4f31b63b3036731df0b47337a7a245
Modified: 2026-02-26
CVE-2022-50537
In the Linux kernel, the following vulnerability has been resolved: firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe() In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will not be freed through rpi_firmware_delete(), fix this leak by calling kfree() in the error path.
- https://git.kernel.org/stable/c/62ac943eb2a9d655e431b9bc98ff6d7bd51a0e49
- https://git.kernel.org/stable/c/6757dd2193fe18c5c5fe3050e7f2ff9dcbd1ff34
- https://git.kernel.org/stable/c/71d2abab374f707ab8ac8dcef191fd2b3b67b8bd
- https://git.kernel.org/stable/c/7b51161696e803fd5f9ad55b20a64c2df313f95c
- https://git.kernel.org/stable/c/b308fdedef095aac14569f810d46edf773ea7d1e
- https://git.kernel.org/stable/c/d34742245e4366579f9a80f8cfe4a63248e838e0
Modified: 2026-02-26
CVE-2022-50538
In the Linux kernel, the following vulnerability has been resolved:
vme: Fix error not catched in fake_init()
In fake_init(), __root_device_register() is possible to fail but it's
ignored, which can cause unregistering vme_root fail when exit.
general protection fault,
probably for non-canonical address 0xdffffc000000008c
KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467]
RIP: 0010:root_device_unregister+0x26/0x60
Call Trace:
- https://git.kernel.org/stable/c/09be0e7ac5f9374b6f8de72c89ed67129af71f65
- https://git.kernel.org/stable/c/37d3de40c1ffb6a5e626bf46ff5ef5766c824e2c
- https://git.kernel.org/stable/c/4bc217b25ea81034fad8e33fd33e4659f086421d
- https://git.kernel.org/stable/c/60ff9bd4ffc87bace581e235a6728f5ac8e5071f
- https://git.kernel.org/stable/c/69b43937f14bdc3594f57f1a507a14f3d1187136
- https://git.kernel.org/stable/c/7bef797d707f1744f71156b21d41e3b8c946631f
- https://git.kernel.org/stable/c/a2a93546d414c7fe4862b87183fb737d1300d9d2
- https://git.kernel.org/stable/c/e831fdd60e5863ee03173baf5a0f7c5450b44381
- https://git.kernel.org/stable/c/f3f65c4177846c483bf009f8c512ab04b3c62466
Modified: 2026-02-26
CVE-2022-50541
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics. These registers are 32-bit hardware counters and the driver uses these counters to monitor the operational progress status for a channel, when transferring more than 4GB of data it was observed that these counters overflow and completion calculation of a operation gets affected and the transfer hangs indefinitely. This commit adds changes to decrease the byte count for every complete transaction so that these registers never overflow and the proper byte count statistics is maintained for ongoing transaction by the RT counters. Earlier uc->bcnt used to maintain a count of the completed bytes at driver side, since the RT counters maintain the statistics of current transaction now, the maintenance of uc->bcnt is not necessary.
Modified: 2026-02-26
CVE-2022-50542
In the Linux kernel, the following vulnerability has been resolved: media: si470x: Fix use-after-free in si470x_int_in_callback() syzbot reported use-after-free in si470x_int_in_callback() [1]. This indicates that urb->context, which contains struct si470x_device object, is freed when si470x_int_in_callback() is called. The cause of this issue is that si470x_int_in_callback() is called for freed urb. si470x_usb_driver_probe() calls si470x_start_usb(), which then calls usb_submit_urb() and si470x_start(). If si470x_start_usb() fails, si470x_usb_driver_probe() doesn't kill urb, but it just frees struct si470x_device object, as depicted below: si470x_usb_driver_probe() ... si470x_start_usb() ... usb_submit_urb() retval = si470x_start() return retval if (retval < 0) free struct si470x_device object, but don't kill urb This patch fixes this issue by killing urb when si470x_start_usb() fails and urb is submitted. If si470x_start_usb() fails and urb is not submitted, i.e. submitting usb fails, it just frees struct si470x_device object.
- https://git.kernel.org/stable/c/0ca298d548461d29615f9a2b1309e8dcf4a352c6
- https://git.kernel.org/stable/c/146bd005ebb01ae190c22af050cb98623958c373
- https://git.kernel.org/stable/c/1c6447d0fc68650e51586dde79b5090d9d77f13a
- https://git.kernel.org/stable/c/52f54fe78cca24850a30865037250f63eb3d5bf7
- https://git.kernel.org/stable/c/63648a7bd1a7599bcc2040a6d1792363ae4c2e1b
- https://git.kernel.org/stable/c/6c8aee0c8fcc6dda94315f7908e8fa9bc75abe75
- https://git.kernel.org/stable/c/7d21e0b1b41b21d628bf2afce777727bd4479aa5
- https://git.kernel.org/stable/c/8c6151b8e8dd2d98ad2cd725d26d1e103d989891
- https://git.kernel.org/stable/c/92b0888398e4ba51d93b618a6506781f4e3879c9
Modified: 2026-02-26
CVE-2022-50544
In the Linux kernel, the following vulnerability has been resolved: usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info() xhci_alloc_stream_info() allocates stream context array for stream_info ->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs, stream_info->stream_ctx_array is not released, which will lead to a memory leak. We can fix it by releasing the stream_info->stream_ctx_array with xhci_free_stream_ctx() on the error path to avoid the potential memory leak.
- https://git.kernel.org/stable/c/782c873f8e7686f5b3c47e8b099f7e08c3dd1fdc
- https://git.kernel.org/stable/c/7e271f42a5cc3768cd2622b929ba66859ae21f97
- https://git.kernel.org/stable/c/7fc6bab3413e6a42bb1264ff7c9149808c93a4c7
- https://git.kernel.org/stable/c/91271a3e772e180bbb8afb114c72fd294a02f93d
- https://git.kernel.org/stable/c/9fa81cbd2dd300aa8fe9bac70e068b9a11cbb144
- https://git.kernel.org/stable/c/a40ad475236022f3432880e3091c380e46e71a71
- https://git.kernel.org/stable/c/ddab9fe76296840aad686c66888a9c1dfdbff5ff
- https://git.kernel.org/stable/c/e702de2f5c893bf2cdb0152191f99a6ad1411823
- https://git.kernel.org/stable/c/fcd594da0b5955119d9707e4e0a8d0fb1c969101
Modified: 2026-02-26
CVE-2022-50545
In the Linux kernel, the following vulnerability has been resolved:
r6040: Fix kmemleak in probe and remove
There is a memory leaks reported by kmemleak:
unreferenced object 0xffff888116111000 (size 2048):
comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s)
hex dump (first 32 bytes):
00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................
08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d
- https://git.kernel.org/stable/c/3d5f83a62e8235d235534b3dc6f197d8a822c269
- https://git.kernel.org/stable/c/5944c25c67de54e0aa53623e1e1af3bf8b16ed44
- https://git.kernel.org/stable/c/7e43039a49c2da45edc1d9d7c9ede4003ab45a5f
- https://git.kernel.org/stable/c/9b5b50329e2e966831a7237dd6949e7b5362a49a
- https://git.kernel.org/stable/c/a04707f4596952049da05756c27398c34d9a1d36
- https://git.kernel.org/stable/c/ad2c8f25457ca9a81e7e958148cbc26600ce3071
- https://git.kernel.org/stable/c/b0a61359026b57a287a48fbb4ba1d097023eca3e
- https://git.kernel.org/stable/c/b4448816e6a565e08236a6009c6bf48c6836cdfd
Modified: 2026-02-26
CVE-2022-50546
In the Linux kernel, the following vulnerability has been resolved: ext4: fix uninititialized value in 'ext4_evict_inode' Syzbot found the following issue: ===================================================== BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 evict+0x365/0x9a0 fs/inode.c:664 iput_final fs/inode.c:1747 [inline] iput+0x985/0xdd0 fs/inode.c:1773 __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844 vfs_mknod+0x79d/0x830 fs/namei.c:3914 do_mknodat+0x47d/0xaa0 __do_sys_mknodat fs/namei.c:3992 [inline] __se_sys_mknodat fs/namei.c:3989 [inline] __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x1b5/0x1010 mm/slub.c:1939 new_slab mm/slub.c:1992 [inline] ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180 __slab_alloc mm/slub.c:3279 [inline] slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3117 [inline] ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321 alloc_inode+0x83/0x440 fs/inode.c:259 new_inode_pseudo fs/inode.c:1018 [inline] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959 ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992 vfs_mkdir+0x62a/0x870 fs/namei.c:4035 do_mkdirat+0x466/0x7b0 fs/namei.c:4060 __do_sys_mkdirat fs/namei.c:4075 [inline] __se_sys_mkdirat fs/namei.c:4073 [inline] __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 ===================================================== Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failed before set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after 6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' which will lead to access uninit-value. To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'.
- https://git.kernel.org/stable/c/091f85db4c3fb1734a6d7fb4777a2b2831da6631
- https://git.kernel.org/stable/c/3c31d8d3ad95aef8cc17a4fcf317e46217148439
- https://git.kernel.org/stable/c/56491d60ddca9c697d885394cb0173675b9ab81f
- https://git.kernel.org/stable/c/7ea71af94eaaaf6d9aed24bc94a05b977a741cb9
- https://git.kernel.org/stable/c/9f966e021c20caae639dd0e404c8761e8281a2c4
- https://git.kernel.org/stable/c/e431b4fb1fb8c2654b808086e9747a000adb9655
- https://git.kernel.org/stable/c/f0bffdcc7cb14598af2aa706f1e0f2a9054154ba
Modified: 2026-02-26
CVE-2022-50547
In the Linux kernel, the following vulnerability has been resolved: media: solo6x10: fix possible memory leak in solo_sysfs_init() If device_register() returns error in solo_sysfs_init(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup().
- https://git.kernel.org/stable/c/49060c0da57a381563e482e331dc9d4c3725b41b
- https://git.kernel.org/stable/c/7b02c50d3978840781808e13bc13137fb81286b5
- https://git.kernel.org/stable/c/7cf71bbe5d2ee12613f6e278888f5fc9c5c0cc2b
- https://git.kernel.org/stable/c/7f5866dd96d95b74e439f6ee17b8abd8195179fb
- https://git.kernel.org/stable/c/83d4b1ae98a47a739fa5241300b86eb1110d5d63
- https://git.kernel.org/stable/c/9416861170ba0da8ddb0f4fd2d28334f0ed3b9c2
- https://git.kernel.org/stable/c/963729538674be4cb8fa292529ecf32de0d6c6dd
- https://git.kernel.org/stable/c/b61509093e1af69e336a094d439b8e1137cb40d8
- https://git.kernel.org/stable/c/d6db105bcfbdbbbd484e788a0ddf8140a4a8c486
Modified: 2026-02-26
CVE-2022-50549
In the Linux kernel, the following vulnerability has been resolved: dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata Following concurrent processes: P1(drop cache) P2(kworker) drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab super_cache_scan prune_icache_sb dispose_list evict ext4_evict_inode ext4_clear_inode ext4_discard_preallocations ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_read_bh_nowait submit_bh dm_submit_bio do_worker process_deferred_bios commit metadata_operation_failed dm_pool_abort_metadata down_write(&pmd->root_lock) - LOCK B __destroy_persistent_data_objects dm_block_manager_destroy dm_bufio_client_destroy unregister_shrinker down_write(&shrinker_rwsem) thin_map | dm_thin_find_block ↓ down_read(&pmd->root_lock) --> ABBA deadlock , which triggers hung task: [ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds. [ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2 [ 76.978534] Workqueue: dm-thin do_worker [ 76.978552] Call Trace: [ 76.978564] __schedule+0x6ba/0x10f0 [ 76.978582] schedule+0x9d/0x1e0 [ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0 [ 76.978600] down_write+0xec/0x110 [ 76.978607] unregister_shrinker+0x2c/0xf0 [ 76.978616] dm_bufio_client_destroy+0x116/0x3d0 [ 76.978625] dm_block_manager_destroy+0x19/0x40 [ 76.978629] __destroy_persistent_data_objects+0x5e/0x70 [ 76.978636] dm_pool_abort_metadata+0x8e/0x100 [ 76.978643] metadata_operation_failed+0x86/0x110 [ 76.978649] commit+0x6a/0x230 [ 76.978655] do_worker+0xc6e/0xd90 [ 76.978702] process_one_work+0x269/0x630 [ 76.978714] worker_thread+0x266/0x630 [ 76.978730] kthread+0x151/0x1b0 [ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds. [ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459 [ 76.982128] Call Trace: [ 76.982139] __schedule+0x6ba/0x10f0 [ 76.982155] schedule+0x9d/0x1e0 [ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910 [ 76.982173] down_read+0x84/0x170 [ 76.982177] dm_thin_find_block+0x4c/0xd0 [ 76.982183] thin_map+0x201/0x3d0 [ 76.982188] __map_bio+0x5b/0x350 [ 76.982195] dm_submit_bio+0x2b6/0x930 [ 76.982202] __submit_bio+0x123/0x2d0 [ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0 [ 76.982222] submit_bio_noacct+0x389/0x770 [ 76.982227] submit_bio+0x50/0xc0 [ 76.982232] submit_bh_wbc+0x15e/0x230 [ 76.982238] submit_bh+0x14/0x20 [ 76.982241] ext4_read_bh_nowait+0xc5/0x130 [ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60 [ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0 [ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0 [ 76.982263] ext4_discard_preallocations+0x45d/0x830 [ 76.982274] ext4_clear_inode+0x48/0xf0 [ 76.982280] ext4_evict_inode+0xcf/0xc70 [ 76.982285] evict+0x119/0x2b0 [ 76.982290] dispose_list+0x43/0xa0 [ 76.982294] prune_icache_sb+0x64/0x90 [ 76.982298] super_cache_scan+0x155/0x210 [ 76.982303] do_shrink_slab+0x19e/0x4e0 [ 76.982310] shrink_slab+0x2bd/0x450 [ 76.982317] drop_slab+0xcc/0x1a0 [ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0 [ 76.982327] proc_sys_call_handler+0x1bc/0x300 [ 76.982331] proc_sys_write+0x17/0x20 [ 76.982334] vfs_write+0x3d3/0x570 [ 76.982342] ksys_write+0x73/0x160 [ 76.982347] __x64_sys_write+0x1e/0x30 [ 76.982352] do_syscall_64+0x35/0x80 [ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcd Funct ---truncated---
- https://git.kernel.org/stable/c/200aa33b5d781e7c0fa6c0c7db9dbcc3f574ce8f
- https://git.kernel.org/stable/c/2d891cc5a1706b6908bceb56af7176a463ee6d62
- https://git.kernel.org/stable/c/7e37578069737b04955c71dd85db8a3bc2709eff
- https://git.kernel.org/stable/c/8111964f1b8524c4bb56b02cd9c7a37725ea21fd
- https://git.kernel.org/stable/c/cdf7a39bcc427febbfe3c3b9fe829825ead96c27
- https://git.kernel.org/stable/c/f8c26c33fef588ee54852cffa7cbb9f9d9869405
Modified: 2026-02-26
CVE-2022-50551
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request() This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITS_PER_TYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example. Found by a modified version of syzkaller. UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea ? brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 ? brcmf_usb_reset_resume+0x120/0x120 ? number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 ? put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 ? rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 ? mark_held_locks+0x9f/0xe0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 ? usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? pr ---truncated---
- https://git.kernel.org/stable/c/0b12d2aa264bac35bff9b5399bb162262b2b8949
- https://git.kernel.org/stable/c/1db036d13e10809943c2dce553e2fa7fc9c6cd80
- https://git.kernel.org/stable/c/4c8fc44c44b97854623c56363c359f711fc0b887
- https://git.kernel.org/stable/c/579c9b9838e8a73f6e93ddece07972c241514dcc
- https://git.kernel.org/stable/c/5b06a8a25eba07628313aa3c5496522eff97be53
- https://git.kernel.org/stable/c/81d17f6f3331f03c8eafdacea68ab773426c1e3c
- https://git.kernel.org/stable/c/87792567d9ed93fd336d2c3b8d7870f44e141e6d
- https://git.kernel.org/stable/c/9d2f70fa2c7cc6c73a420ff15682454782d3d6f6
- https://git.kernel.org/stable/c/bc45aa1911bf699b9905f12414e3c1879d6b784f
- https://git.kernel.org/stable/c/ffb589963df103caaf062081a32db0b9e1798660
Modified: 2026-02-04
CVE-2022-50553
In the Linux kernel, the following vulnerability has been resolved:
tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'
When generate a synthetic event with many params and then create a trace
action for it [1], kernel panic happened [2].
It is because that in trace_action_create() 'data->n_params' is up to
SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'
keeps indices into array 'hist_data->var_refs' for each synthetic event
param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX
(current value is 16), so out-of-bound write happened when 'data->n_params'
more than 16. In this case, 'data->match_data.event' is overwritten and
eventually cause the panic.
To solve the issue, adjust the length of 'data->var_ref_idx' to be
SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.
[1]
# cd /sys/kernel/tracing/
# echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\
int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\
int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\
int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\
int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\
int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\
int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\
int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\
int v63" >> synthetic_events
# echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="bash"' >> \
events/sched/sched_waking/trigger
# echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\
pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\
pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\
pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\
pid,pid,pid,pid,pid,pid,pid,pid,pid)" >> events/sched/sched_switch/trigger
[2]
BUG: unable to handle page fault for address: ffff91c900000000
PGD 61001067 P4D 61001067 PUD 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:strcmp+0xc/0x30
Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee
c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14
07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3
RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000
RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000
RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000
R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580
R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538
FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0
Call Trace:
- https://git.kernel.org/stable/c/04241956ce8825ff06e06e4083e7b692e9d5f712
- https://git.kernel.org/stable/c/0cb31bd88361edb96cfc622648717ba348f0f4dc
- https://git.kernel.org/stable/c/15697f653399253f9be4ed2a1e03d795f3cfee94
- https://git.kernel.org/stable/c/82470f7d9044842618c847a7166de2b7458157a7
- https://git.kernel.org/stable/c/b4efdc219fb8cfa066c7042e636ab8ad6d7e7494
- https://git.kernel.org/stable/c/cf79d5410a569dad1d4112b5c3c02383cca8213a
Modified: 2026-02-05
CVE-2022-50555
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a null-ptr-deref in tipc_topsrv_accept
syzbot found a crash in tipc_topsrv_accept:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
Workqueue: tipc_rcv tipc_topsrv_accept
RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487
Call Trace:
- https://git.kernel.org/stable/c/24b129aed8730e48f47d852d58d76825ab6f407c
- https://git.kernel.org/stable/c/32a3d4660b34ce49ac0162338ebe362098e2f5df
- https://git.kernel.org/stable/c/7a939503fc32bff4ed60800b73ff7fbb4aea2142
- https://git.kernel.org/stable/c/82cb4e4612c633a9ce320e1773114875604a3cce
- https://git.kernel.org/stable/c/ce69bdac2310152bb70845024d5d704c52aabfc3
- https://git.kernel.org/stable/c/cedb41664e27b2cae7e21487f1bee22dcd84037d
Modified: 2025-02-13
CVE-2023-0045
The current implementation of the prctl syscall does not issue an IBPB immediately during the syscall. The ib_prctl_set function updates the Thread Information Flags (TIFs) for the task and updates the SPEC_CTRL MSR on the function __speculation_ctrl_update, but the IBPB is only issued on the next schedule, when the TIF bits are checked. This leaves the victim vulnerable to values already injected on the BTB, prior to the prctl syscall. The patch that added the support for the conditional mitigation via prctl (ib_prctl_set) dates back to the kernel 4.9.176. We recommend upgrading past commit a664ec9158eeddd75121d39c9a0758016097fa96
- https://git.kernel.org/tip/a664ec9158eeddd75121d39c9a0758016097fa96
- https://github.com/google/security-research/security/advisories/GHSA-9x5g-vmxf-4qj8
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230714-0001/
- https://git.kernel.org/tip/a664ec9158eeddd75121d39c9a0758016097fa96
- https://github.com/google/security-research/security/advisories/GHSA-9x5g-vmxf-4qj8
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230714-0001/
Modified: 2024-11-21
CVE-2023-0179
A buffer overflow vulnerability was found in the Netfilter subsystem in the Linux Kernel. This issue could allow the leakage of both stack and heap addresses, and potentially allow Local Privilege Escalation to the root user via arbitrary code execution.
- http://packetstormsecurity.com/files/171601/Kernel-Live-Patch-Security-Notice-LNS-0093-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2161713
- https://seclists.org/oss-sec/2023/q1/20
- https://security.netapp.com/advisory/ntap-20230511-0003/
- http://packetstormsecurity.com/files/171601/Kernel-Live-Patch-Security-Notice-LNS-0093-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2161713
- https://seclists.org/oss-sec/2023/q1/20
- https://security.netapp.com/advisory/ntap-20230511-0003/
Modified: 2024-11-21
CVE-2023-0210
A bug affects the Linux kernel’s ksmbd NTLMv2 authentication and is known to crash the OS immediately in Linux-based systems.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797805d81baa814f76cf7bdab35f86408a79d707
- https://github.com/cifsd-team/ksmbd/commit/8824b7af409f51f1316e92e9887c2fd48c0b26d6
- https://security.netapp.com/advisory/ntap-20230517-0002/
- https://securityonline.info/cve-2023-0210-flaw-in-linux-kernel-allows-unauthenticated-remote-dos-attacks/
- https://www.openwall.com/lists/oss-security/2023/01/04/1
- https://www.openwall.com/lists/oss-security/2023/01/11/1
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797805d81baa814f76cf7bdab35f86408a79d707
- https://github.com/cifsd-team/ksmbd/commit/8824b7af409f51f1316e92e9887c2fd48c0b26d6
- https://security.netapp.com/advisory/ntap-20230517-0002/
- https://securityonline.info/cve-2023-0210-flaw-in-linux-kernel-allows-unauthenticated-remote-dos-attacks/
- https://www.openwall.com/lists/oss-security/2023/01/04/1
- https://www.openwall.com/lists/oss-security/2023/01/11/1
Modified: 2025-10-24
CVE-2023-0266
A use after free vulnerability exists in the ALSA PCM package in the Linux Kernel. SNDRV_CTL_IOCTL_ELEM_{READ|WRITE}32 is missing locks that can be used in a use-after-free that can result in a priviledge escalation to gain ring0 access from the system user. We recommend upgrading past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/alsa-pcm-move-rwsem-lock-inside-snd_ctl_elem_read-to-prevent-uaf.patch?id=72783cf35e6c55bca84c4bb7b776c58152856fd4
- https://github.com/torvalds/linux/commit/56b88b50565cd8b946a2d00b0c83927b7ebb055e
- https://github.com/torvalds/linux/commit/becf9e5d553c2389d857a3c178ce80fdb34a02e1
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/alsa-pcm-move-rwsem-lock-inside-snd_ctl_elem_read-to-prevent-uaf.patch?id=72783cf35e6c55bca84c4bb7b776c58152856fd4
- https://github.com/torvalds/linux/commit/56b88b50565cd8b946a2d00b0c83927b7ebb055e
- https://github.com/torvalds/linux/commit/becf9e5d553c2389d857a3c178ce80fdb34a02e1
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-0266
Modified: 2025-11-04
CVE-2023-0386
A flaw was found in the Linux kernel, where unauthorized access to the execution of the setuid file with capabilities was found in the Linux kernel’s OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount. This uid mapping bug allows a local user to escalate their privileges on the system.
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f11ada10d0a
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20230420-0004/
- https://www.debian.org/security/2023/dsa-5402
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f11ada10d0a
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20230420-0004/
- https://www.debian.org/security/2023/dsa-5402
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-0386
Modified: 2024-11-21
CVE-2023-0461
There is a use-after-free vulnerability in the Linux Kernel which can be exploited to achieve local privilege escalation. To reach the vulnerability kernel configuration flag CONFIG_TLS or CONFIG_XFRM_ESPINTCP has to be configured, but the operation does not require any privilege. There is a use-after-free bug of icsk_ulp_data of a struct inet_connection_sock. When CONFIG_TLS is enabled, user can install a tls context (struct tls_context) on a connected tcp socket. The context is not cleared if this socket is disconnected and reused as a listener. If a new socket is created from the listener, the context is inherited and vulnerable. The setsockopt TCP_ULP operation does not require any privilege. We recommend upgrading past commit 2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://kernel.dance/#2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://kernel.dance/#2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230331-0006/
Modified: 2025-02-18
CVE-2023-1652
A use-after-free flaw was found in nfsd4_ssc_setup_dul in fs/nfsd/nfs4proc.c in the NFS filesystem in the Linux Kernel. This issue could allow a local attacker to crash the system or it may lead to a kernel information leak problem.
Modified: 2025-04-23
CVE-2023-2006
A race condition was found in the Linux kernel's RxRPC network protocol, within the processing of RxRPC bundles. This issue results from the lack of proper locking when performing operations on an object. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel.
- https://bugzilla.redhat.com/show_bug.cgi?id=2189112
- https://github.com/torvalds/linux/commit/3bcd6c7eaa53
- https://security.netapp.com/advisory/ntap-20230609-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-439/
- https://bugzilla.redhat.com/show_bug.cgi?id=2189112
- https://github.com/torvalds/linux/commit/3bcd6c7eaa53
- https://security.netapp.com/advisory/ntap-20230609-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-439/
Modified: 2025-05-05
CVE-2023-23559
In rndis_query_oid in drivers/net/wireless/rndis_wlan.c in the Linux kernel through 6.1.5, there is an integer overflow in an addition.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b870e73a56c4cccbec33224233eaf295839f228c
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://patchwork.kernel.org/project/linux-wireless/patch/20230110173007.57110-1-szymon.heidrich%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230302-0003/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b870e73a56c4cccbec33224233eaf295839f228c
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://patchwork.kernel.org/project/linux-wireless/patch/20230110173007.57110-1-szymon.heidrich%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230302-0003/
Modified: 2025-05-05
CVE-2023-26544
In the Linux kernel 6.0.8, there is a use-after-free in run_unpack in fs/ntfs3/run.c, related to a difference between NTFS sector size and media sector size.
- https://bugzilla.suse.com/show_bug.cgi?id=1208697
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=887bfc546097fbe8071dac13b2fef73b77920899
- https://lkml.org/lkml/2023/2/20/128
- https://security.netapp.com/advisory/ntap-20230316-0010/
- https://bugzilla.suse.com/show_bug.cgi?id=1208697
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=887bfc546097fbe8071dac13b2fef73b77920899
- https://lkml.org/lkml/2023/2/20/128
- https://security.netapp.com/advisory/ntap-20230316-0010/
Modified: 2025-05-05
CVE-2023-26606
In the Linux kernel 6.0.8, there is a use-after-free in ntfs_trim_fs in fs/ntfs3/bitmap.c.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=557d19675a470bb0a98beccec38c5dc3735c20fa
- https://lkml.org/lkml/2023/2/20/860
- https://security.netapp.com/advisory/ntap-20230316-0010/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=557d19675a470bb0a98beccec38c5dc3735c20fa
- https://lkml.org/lkml/2023/2/20/860
- https://security.netapp.com/advisory/ntap-20230316-0010/
Modified: 2025-05-05
CVE-2023-26607
In the Linux kernel 6.0.8, there is an out-of-bounds read in ntfs_attr_find in fs/ntfs/attrib.c.
- https://bugzilla.suse.com/show_bug.cgi?id=1208703
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36a4d82dddbbd421d2b8e79e1cab68c8126d5075
- https://lkml.org/lkml/2023/2/21/1353
- https://security.netapp.com/advisory/ntap-20230316-0010/
- https://bugzilla.suse.com/show_bug.cgi?id=1208703
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36a4d82dddbbd421d2b8e79e1cab68c8126d5075
- https://lkml.org/lkml/2023/2/21/1353
- https://security.netapp.com/advisory/ntap-20230316-0010/
Modified: 2024-11-21
CVE-2023-3812
An out-of-bounds memory access flaw was found in the Linux kernel’s TUN/TAP device driver functionality in how a user generates a malicious (too big) networking packet when napi frags is enabled. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
Modified: 2024-09-11
CVE-2023-52893
In the Linux kernel, the following vulnerability has been resolved: gsmi: fix null-deref in gsmi_get_variable We can get EFI variables without fetching the attribute, so we must allow for that in gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.
- https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a
- https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393
- https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8
- https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd
- https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2
- https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b
- https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5
Modified: 2024-09-11
CVE-2023-52894
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate() In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device. AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b) Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c] which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); which calls: ncm_bitrate(NULL) which then calls: gadget_is_superspeed(NULL) which reads ((struct usb_gadget *)NULL)->max_speed and hits a panic. AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct work_struct) It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing...
- https://git.kernel.org/stable/c/09e4507ec8ef2d44da6ba4092b8ee2d81f216497
- https://git.kernel.org/stable/c/63d161f29cd39c050e8873aa36e0c9fc013bb763
- https://git.kernel.org/stable/c/a21da7f7aae618c785f7e4a275d43c06dc8412b6
- https://git.kernel.org/stable/c/a69c8dfb85b44be9cc223be07d35cc3a9baefbea
- https://git.kernel.org/stable/c/c6ec929595c7443250b2a4faea988c62019d5cd2
- https://git.kernel.org/stable/c/e92c70059178da751e5af7de02384b7dfadb5ec7
- https://git.kernel.org/stable/c/fef6b29671b66dfb71f17e337c1ad14b5a2cedae
Modified: 2024-09-11
CVE-2023-52896
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race between quota rescan and disable leading to NULL pointer deref
If we have one task trying to start the quota rescan worker while another
one is trying to disable quotas, we can end up hitting a race that results
in the quota rescan worker doing a NULL pointer dereference. The steps for
this are the following:
1) Quotas are enabled;
2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().
It calls qgroup_rescan_init() which returns 0 (success) and then joins a
transaction and commits it;
3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().
It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info->flags and calls
btrfs_qgroup_wait_for_completion(), which returns immediately since the
rescan worker is not yet running.
Then it starts a transaction and locks fs_info->qgroup_ioctl_lock;
4) Task A queues the rescan worker, by calling btrfs_queue_work();
5) The rescan worker starts, and calls rescan_should_stop() at the start
of its while loop, which results in 0 iterations of the loop, since
the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info->flags by
task B at step 3);
6) Task B sets fs_info->quota_root to NULL;
7) The rescan worker tries to start a transaction and uses
fs_info->quota_root as the root argument for btrfs_start_transaction().
This results in a NULL pointer dereference down the call chain of
btrfs_start_transaction(). The stack trace is something like the one
reported in Link tag below:
general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: btrfs-qgroup-rescan btrfs_work_helper
RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564
Code: 48 89 fb 48 (...)
RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206
RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d
R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1004fc90f0d79a4b7d9e3d432729914f472f9ad1
- https://git.kernel.org/stable/c/3bd43374857103ba3cac751d6d4afa8d83b5d92a
- https://git.kernel.org/stable/c/64287cd456a22373053998c1fccf14b651e9cbbd
- https://git.kernel.org/stable/c/89ac597e3e807b91e2ebd6a7c36fec7b97290233
- https://git.kernel.org/stable/c/b7adbf9ada3513d2092362c8eac5cddc5b651f5c
Modified: 2024-09-13
CVE-2023-52898
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix null pointer dereference when host dies Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies. Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id] virt device at the same time that xhci_kill_endpoint_urbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back. hold the xhci spinlock while freeing the virt device
- https://git.kernel.org/stable/c/081105213ff6f661c114781d469233c7d0e09c2e
- https://git.kernel.org/stable/c/133b902378e4acbd824c29dd0d48570ad596e368
- https://git.kernel.org/stable/c/6fac4b5cecb3928a0a81069aaa815a2edc8dd5a1
- https://git.kernel.org/stable/c/a2bc47c43e70cf904b1af49f76d572326c08bca7
- https://git.kernel.org/stable/c/c462ac871f49753eca86bb960f573b993976a5ea
- https://git.kernel.org/stable/c/ea2ee5e9991caf74e0604f994c1831a5867055b2
Modified: 2024-09-13
CVE-2023-52899
In the Linux kernel, the following vulnerability has been resolved: Add exception protection processing for vd in axi_chan_handle_err function Since there is no protection for vd, a kernel panic will be triggered here in exceptional cases. You can refer to the processing of axi_chan_block_xfer_complete function The triggered kernel panic is as follows: [ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 67.848447] Mem abort info: [ 67.848449] ESR = 0x96000004 [ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.848454] SET = 0, FnV = 0 [ 67.848456] EA = 0, S1PTW = 0 [ 67.848458] Data abort info: [ 67.848460] ISV = 0, ISS = 0x00000004 [ 67.848462] CM = 0, WnR = 0 [ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000 [ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000 [ 67.848472] Internal error: Oops: 96000004 [#1] SMP [ 67.848475] Modules linked in: dmatest [ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11 [ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--) [ 67.848487] pc : axi_chan_handle_err+0xc4/0x230 [ 67.848491] lr : axi_chan_handle_err+0x30/0x230 [ 67.848493] sp : ffff0803fe55ae50 [ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200 [ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080 [ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850 [ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000 [ 67.848512] x21: 0000000000000080 x20: 0000000000002000 [ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000 [ 67.848521] x17: 0000000000000000 x16: 0000000000000000 [ 67.848525] x15: 0000000000000000 x14: 0000000000000000 [ 67.848529] x13: 0000000000000000 x12: 0000000000000040 [ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a [ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270 [ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0 [ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480 [ 67.848550] x3 : dead000000000100 x2 : dead000000000122 [ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168 [ 67.848559] Call trace: [ 67.848562] axi_chan_handle_err+0xc4/0x230 [ 67.848566] dw_axi_dma_interrupt+0xf4/0x590 [ 67.848569] __handle_irq_event_percpu+0x60/0x220 [ 67.848573] handle_irq_event+0x64/0x120 [ 67.848576] handle_fasteoi_irq+0xc4/0x220 [ 67.848580] __handle_domain_irq+0x80/0xe0 [ 67.848583] gic_handle_irq+0xc0/0x138 [ 67.848585] el1_irq+0xc8/0x180 [ 67.848588] arch_cpu_idle+0x14/0x2c [ 67.848591] default_idle_call+0x40/0x16c [ 67.848594] do_idle+0x1f0/0x250 [ 67.848597] cpu_startup_entry+0x2c/0x60 [ 67.848600] rest_init+0xc0/0xcc [ 67.848603] arch_call_rest_init+0x14/0x1c [ 67.848606] start_kernel+0x4cc/0x500 [ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1) [ 67.848613] ---[ end trace 585a97036f88203a ]---
- https://git.kernel.org/stable/c/20d0a6d17e85a8a816a64fa7d7cae616f1617833
- https://git.kernel.org/stable/c/5054d001ffaf76155637c5e5b922c11016cd6a5d
- https://git.kernel.org/stable/c/51a7ad5b60efac65691729d10745c28fa1016b96
- https://git.kernel.org/stable/c/53dd833fd0a2d8f0118d01ea063a70652689d31e
- https://git.kernel.org/stable/c/57054fe516d59d03a7bcf1888e82479ccc244f87
- https://git.kernel.org/stable/c/f534dc438828cc3f1f8c6895b8bdfbef079521fb
Modified: 2024-09-13
CVE-2023-52900
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix general protection fault in nilfs_btree_insert()
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node
block by calling __nilfs_btree_get_block() against an invalid virtual
block address, it returns -ENOENT because conversion of the virtual block
address to a disk block address fails. However, this return value is the
same as the internal code that b-tree lookup routines return to indicate
that the block being searched does not exist, so functions that operate on
that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not found' code from
nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was
successful and continues the insert operation using incomplete lookup path
data, causing the following crash:
general protection fault, probably for non-canonical address
0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
...
RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]
RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]
RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238
Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89
ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c
28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02
...
Call Trace:
- https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04
- https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545
- https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062
- https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243
- https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051
- https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d
- https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749
Modified: 2024-09-13
CVE-2023-52901
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Check endpoint is valid before dereferencing it When the host controller is not responding, all URBs queued to all endpoints need to be killed. This can cause a kernel panic if we dereference an invalid endpoint. Fix this by using xhci_get_virt_ep() helper to find the endpoint and checking if the endpoint is valid before dereferencing it. [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8 [233311.853964] pc : xhci_hc_died+0x10c/0x270 [233311.853971] lr : xhci_hc_died+0x1ac/0x270 [233311.854077] Call trace: [233311.854085] xhci_hc_died+0x10c/0x270 [233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4 [233311.854105] call_timer_fn+0x50/0x2d4 [233311.854112] expire_timers+0xac/0x2e4 [233311.854118] run_timer_softirq+0x300/0xabc [233311.854127] __do_softirq+0x148/0x528 [233311.854135] irq_exit+0x194/0x1a8 [233311.854143] __handle_domain_irq+0x164/0x1d0 [233311.854149] gic_handle_irq.22273+0x10c/0x188 [233311.854156] el1_irq+0xfc/0x1a8 [233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm] [233311.854185] cpuidle_enter_state+0x1f0/0x764 [233311.854194] do_idle+0x594/0x6ac [233311.854201] cpu_startup_entry+0x7c/0x80 [233311.854209] secondary_start_kernel+0x170/0x198
- https://git.kernel.org/stable/c/08864dc14a6803f0377ca77b9740b26db30c020f
- https://git.kernel.org/stable/c/2d2820d5f375563690c96e60676855205abfb7f5
- https://git.kernel.org/stable/c/375be2dd61a072f7b1cac9b17eea59e07b58db3a
- https://git.kernel.org/stable/c/66fc1600855c05c4ba4e997184c91cf298e0405c
- https://git.kernel.org/stable/c/9891e5c73cab3fd9ed532dc50e9799e55e974766
- https://git.kernel.org/stable/c/e8fb5bc76eb86437ab87002d4a36d6da02165654
- https://git.kernel.org/stable/c/f39c813af0b64f44af94e435c07bfa1ddc2575f5
Modified: 2024-09-13
CVE-2023-52903
In the Linux kernel, the following vulnerability has been resolved: io_uring: lock overflowing for IOPOLL syzbot reports an issue with overflow filling for IOPOLL: WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: events_unbound io_ring_exit_work Call trace: io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773 io_fill_cqe_req io_uring/io_uring.h:168 [inline] io_do_iopoll+0x474/0x62c io_uring/rw.c:1065 io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513 io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056 io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869 process_one_work+0x2d8/0x504 kernel/workqueue.c:2289 worker_thread+0x340/0x610 kernel/workqueue.c:2436 kthread+0x12c/0x158 kernel/kthread.c:376 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863 There is no real problem for normal IOPOLL as flush is also called with uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which __io_cqring_overflow_flush() happens from the CQ waiting path.
Modified: 2024-09-13
CVE-2023-52906
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mpls: Fix warning during failed attribute validation
The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a
validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid
combination according to the comment above 'struct nla_policy':
"
Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
NLA_BINARY Validation function called for the attribute.
All other Unused - but note that it's a union
"
This can trigger the warning [1] in nla_get_range_unsigned() when
validation of the attribute fails. Despite being of 'NLA_U32' type, the
associated 'min'/'max' fields in the policy are negative as they are
aliased by the 'validate' field.
Fix by changing the attribute type to 'NLA_BINARY' which is consistent
with the above comment and all other users of NLA_POLICY_VALIDATE_FN().
As a result, move the length validation to the validation function.
No regressions in MPLS tests:
# ./tdc.py -f tc-tests/actions/mpls.json
[...]
# echo $?
0
[1]
WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
Modules linked in:
CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
[...]
Call Trace:
- https://git.kernel.org/stable/c/2b157c3c5d6b8ddca48d53c9e662032f65af8d61
- https://git.kernel.org/stable/c/453277feb41c2235cf2c0de9209eef962c401457
- https://git.kernel.org/stable/c/8a97b544b98e44f596219ebb290fd2ba2fd5d644
- https://git.kernel.org/stable/c/9e17f99220d111ea031b44153fdfe364b0024ff2
- https://git.kernel.org/stable/c/9e2c38827cdc6fdd3bb375c8607fc04d289756f9
Modified: 2024-09-12
CVE-2023-52907
In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame() Fix a use-after-free that occurs in hcd when in_urb sent from pn533_usb_send_frame() is completed earlier than out_urb. Its callback frees the skb data in pn533_send_async_complete() that is used as a transfer buffer of out_urb. Wait before sending in_urb until the callback of out_urb is called. To modify the callback of out_urb alone, separate the complete function of out_urb and ack_urb. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in dummy_timer Call Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803)
- https://git.kernel.org/stable/c/0ca78c99656f5c448567db1e148367aa3b01c80a
- https://git.kernel.org/stable/c/321db5131c92983dac4f3338e8fbb6df214238c0
- https://git.kernel.org/stable/c/35529d6b827eedb6bf7e81130e4b7e0aba9e58d2
- https://git.kernel.org/stable/c/39ae73e581112cfe27ba50aecb1c891ce57cecb1
- https://git.kernel.org/stable/c/8998db5021a28ad67aa8d627bdb4226e4046ccc4
- https://git.kernel.org/stable/c/9424d2205fe94a095fb9365ec0c6137f0b394a2b
- https://git.kernel.org/stable/c/9dab880d675b9d0dd56c6428e4e8352a3339371d
Modified: 2024-09-12
CVE-2023-52910
In the Linux kernel, the following vulnerability has been resolved: iommu/iova: Fix alloc iova overflows issue In __alloc_and_insert_iova_range, there is an issue that retry_pfn overflows. The value of iovad->anchor.pfn_hi is ~0UL, then when iovad->cached_node is iovad->anchor, curr_iova->pfn_hi + 1 will overflow. As a result, if the retry logic is executed, low_pfn is updated to 0, and then new_pfn < low_pfn returns false to make the allocation successful. This issue occurs in the following two situations: 1. The first iova size exceeds the domain size. When initializing iova domain, iovad->cached_node is assigned as iovad->anchor. For example, the iova domain size is 10M, start_pfn is 0x1_F000_0000, and the iova size allocated for the first time is 11M. The following is the log information, new->pfn_lo is smaller than iovad->cached_node. Example log as follows: [ 223.798112][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00 [ 223.799590][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range success start_pfn:0x1f0000,new->pfn_lo:0x1efe00,new->pfn_hi:0x1f08ff 2. The node with the largest iova->pfn_lo value in the iova domain is deleted, iovad->cached_node will be updated to iovad->anchor, and then the alloc iova size exceeds the maximum iova size that can be allocated in the domain. After judging that retry_pfn is less than limit_pfn, call retry_pfn+1 to fix the overflow issue.
Modified: 2025-10-01
CVE-2023-52991
In the Linux kernel, the following vulnerability has been resolved:
net: fix NULL pointer in skb_segment_list
Commit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
introduced UDP listifyed GRO. The segmentation relies on frag_list being
untouched when passing through the network stack. This assumption can be
broken sometimes, where frag_list itself gets pulled into linear area,
leaving frag_list being NULL. When this happens it can trigger
following NULL pointer dereference, and panic the kernel. Reverse the
test condition should fix it.
[19185.577801][ C1] BUG: kernel NULL pointer dereference, address:
...
[19185.663775][ C1] RIP: 0010:skb_segment_list+0x1cc/0x390
...
[19185.834644][ C1] Call Trace:
[19185.841730][ C1]
Modified: 2025-10-29
CVE-2023-52992
In the Linux kernel, the following vulnerability has been resolved:
bpf: Skip task with pid=1 in send_signal_common()
The following kernel panic can be triggered when a task with pid=1 attaches
a prog that attempts to send killing signal to itself, also see [1] for more
details:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148
Call Trace:
- https://git.kernel.org/stable/c/0dfef503133565fa0bcf3268d8eeb5b181191a65
- https://git.kernel.org/stable/c/1283a01b6e19d05f7ed49584ea653947245cd41e
- https://git.kernel.org/stable/c/4923160393b06a34759a11b17930d71e06f396f2
- https://git.kernel.org/stable/c/a1c0263f1eb4deee132e11e52ee6982435460d81
- https://git.kernel.org/stable/c/a3d81bc1eaef48e34dd0b9b48eefed9e02a06451
Modified: 2025-10-01
CVE-2023-52993
In the Linux kernel, the following vulnerability has been resolved: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code. This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference. The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type. Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.
- https://git.kernel.org/stable/c/0b08201158f177aab469e356b4d6af24fdd118df
- https://git.kernel.org/stable/c/137f1b47da5f58805da42c1b7811e28c1e353f39
- https://git.kernel.org/stable/c/496975d1a2937f4baadf3d985991b13fc4fc4f27
- https://git.kernel.org/stable/c/5fa55950729d0762a787451dc52862c3f850f859
- https://git.kernel.org/stable/c/744fe9be9665227335539b7a77ece8d9ff62b6c0
- https://git.kernel.org/stable/c/8770cd9d7c14aa99c255a0d08186f0be953e1638
- https://git.kernel.org/stable/c/e284c273dbb4c1ed68d4204bff94d0b10e4a90f5
Modified: 2025-10-29
CVE-2023-52995
In the Linux kernel, the following vulnerability has been resolved:
riscv/kprobe: Fix instruction simulation of JALR
Set kprobe at 'jalr 1140(ra)' of vfs_write results in the following
crash:
[ 32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170
[ 32.093115] Oops [#1]
[ 32.093251] Modules linked in:
[ 32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16
[ 32.093985] Hardware name: riscv-virtio,qemu (DT)
[ 32.094280] epc : ksys_read+0x88/0xd6
[ 32.094855] ra : ksys_read+0xc0/0xd6
[ 32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0
[ 32.095227] gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80
[ 32.095500] t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60
[ 32.095716] s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708
[ 32.095921] a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300
[ 32.096171] a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff
[ 32.096411] s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170
[ 32.096638] s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030
[ 32.096865] s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410
[ 32.097092] s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c
[ 32.097317] t5 : ffffffff8000c29c t6 : ffffffff800dbc54
[ 32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d
[ 32.098011] [
Modified: 2025-10-30
CVE-2023-52996
In the Linux kernel, the following vulnerability has been resolved: ipv4: prevent potential spectre v1 gadget in fib_metrics_match() if (!type) continue; if (type > RTAX_MAX) return false; ... fi_val = fi->fib_metrics->metrics[type - 1]; @type being used as an array index, we need to prevent cpu speculation or risk leaking kernel memory content.
- https://git.kernel.org/stable/c/5e9398a26a92fc402d82ce1f97cc67d832527da0
- https://git.kernel.org/stable/c/7f9828fb1f688210e681268490576f0ca65c322a
- https://git.kernel.org/stable/c/8f0eb24f1a7a60ce635f0d757a46f1a37a4d467d
- https://git.kernel.org/stable/c/ca3cf947760de050d558293002ad3e7f4b8745d2
- https://git.kernel.org/stable/c/f9753ebd61be2d957b5504cbd3fd719674f05b7a
Modified: 2025-10-30
CVE-2023-52997
In the Linux kernel, the following vulnerability has been resolved: ipv4: prevent potential spectre v1 gadget in ip_metrics_convert() if (!type) continue; if (type > RTAX_MAX) return -EINVAL; ... metrics[type - 1] = val; @type being used as an array index, we need to prevent cpu speculation or risk leaking kernel memory content.
- https://git.kernel.org/stable/c/1d1d63b612801b3f0a39b7d4467cad0abd60e5c8
- https://git.kernel.org/stable/c/34c6142f0df9cd75cba5a7aa9df0960d2854b415
- https://git.kernel.org/stable/c/6850fe301d015a7d2012d1de8caf43dafb7cc2f6
- https://git.kernel.org/stable/c/746db9ec1e672eee13965625ddac0d97e16fa20c
- https://git.kernel.org/stable/c/d50e7348b44f1e046121ff5be01b7fb6978a1149
- https://git.kernel.org/stable/c/ef050cf5fb70d995a0d03244e25179b7c66a924a
Modified: 2025-10-30
CVE-2023-53000
In the Linux kernel, the following vulnerability has been resolved: netlink: prevent potential spectre v1 gadgets Most netlink attributes are parsed and validated from __nla_validate_parse() or validate_nla() u16 type = nla_type(nla); if (type == 0 || type > maxtype) { /* error or continue */ } @type is then used as an array index and can be used as a Spectre v1 gadget. array_index_nospec() can be used to prevent leaking content of kernel memory to malicious users. This should take care of vast majority of netlink uses, but an audit is needed to take care of others where validation is not yet centralized in core netlink functions.
- https://git.kernel.org/stable/c/3e5082b1c66c7783fbcd79b5b178573230e528ff
- https://git.kernel.org/stable/c/41b74e95f297ac360ca7ed6bf200100717cb6c45
- https://git.kernel.org/stable/c/539ca5dcbc91134bbe2c45677811c31d8b030d2d
- https://git.kernel.org/stable/c/992e4ff7116a77968039277b5d6aaa535c2f2184
- https://git.kernel.org/stable/c/f0950402e8c76e7dcb08563f1b4e8000fbc62455
Modified: 2025-04-01
CVE-2023-53003
In the Linux kernel, the following vulnerability has been resolved: EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info The memory for llcc_driv_data is allocated by the LLCC driver. But when it is passed as the private driver info to the EDAC core, it will get freed during the qcom_edac driver release. So when the qcom_edac driver gets probed again, it will try to use the freed data leading to the use-after-free bug. Hence, do not pass llcc_driv_data as pvt_info but rather reference it using the platform_data pointer in the qcom_edac driver.
- https://git.kernel.org/stable/c/66e10d5f399629ef7877304d9ba2b35d0474e7eb
- https://git.kernel.org/stable/c/6f0351d0c311951b8b3064db91e61841e85b2b96
- https://git.kernel.org/stable/c/76d9ebb7f0bc10fbc78b6d576751552edf743968
- https://git.kernel.org/stable/c/977c6ba624f24ae20cf0faee871257a39348d4a9
- https://git.kernel.org/stable/c/bff5243bd32661cf9ce66f6d9210fc8f89bda145
Modified: 2025-10-01
CVE-2023-53005
In the Linux kernel, the following vulnerability has been resolved: trace_events_hist: add check for return value of 'create_hist_field' Function 'create_hist_field' is called recursively at trace_events_hist.c:1954 and can return NULL-value that's why we have to check it to avoid null pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/31b2414abeaa6de0490e85164badc6dcb1bb8ec9
- https://git.kernel.org/stable/c/592ba7116fa620425725ff0972691f352ba3caf6
- https://git.kernel.org/stable/c/886aa449235f478e262bbd5dcdee6ed6bc202949
- https://git.kernel.org/stable/c/8b152e9150d07a885f95e1fd401fc81af202d9a4
- https://git.kernel.org/stable/c/b4e7e81b4fdfcf457daee6b7a61769f62198d840
- https://git.kernel.org/stable/c/d2d1ada58e7cc100b8d7d6b082d19321ba4a700a
Modified: 2025-10-30
CVE-2023-53006
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix oops due to uncleared server->smbd_conn in reconnect In smbd_destroy(), clear the server->smbd_conn pointer after freeing the smbd_connection struct that it points to so that reconnection doesn't get confused.
- https://git.kernel.org/stable/c/4b83bc6f87eedab4599b0123e572a422689444be
- https://git.kernel.org/stable/c/5109607a4ece7cd8536172bf7549eb4dce1f3576
- https://git.kernel.org/stable/c/91be54849d5392050f5b847b42bd5e6221551ac8
- https://git.kernel.org/stable/c/a9640c0b268405f2540e8203a545e930ea88bb7d
- https://git.kernel.org/stable/c/b7ab9161cf5ddc42a288edf9d1a61f3bdffe17c7
- https://git.kernel.org/stable/c/e037baee16e0b9ace7e730888fcae9cec11daff2
Modified: 2025-10-30
CVE-2023-53007
In the Linux kernel, the following vulnerability has been resolved:
tracing: Make sure trace_printk() can output as soon as it can be used
Currently trace_printk() can be used as soon as early_trace_init() is
called from start_kernel(). But if a crash happens, and
"ftrace_dump_on_oops" is set on the kernel command line, all you get will
be:
[ 0.456075]
- https://git.kernel.org/stable/c/198c83963f6335ca6d690cff067679560f2a3a22
- https://git.kernel.org/stable/c/3bb06eb6e9acf7c4a3e1b5bc87aed398ff8e2253
- https://git.kernel.org/stable/c/76b2390fdc80c0a8300e5da5b6b62d201b6fe9ce
- https://git.kernel.org/stable/c/b0af180514edea6c83dc9a299d9f383009c99f25
- https://git.kernel.org/stable/c/b94d7c7654356860dd7719120c7d15ba38b6162a
- https://git.kernel.org/stable/c/de3930a4883ddad2244efd6d349013294c62c75c
- https://git.kernel.org/stable/c/f97eb0ab066133483a65c93eb894748de2f6b598
Modified: 2025-10-01
CVE-2023-53011
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: enable all safety features by default In the original implementation of dwmac5 commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features") all safety features were enabled by default. Later it seems some implementations didn't have support for all the features, so in commit 5ac712dcdfef ("net: stmmac: enable platform specific safety features") the safety_feat_cfg structure was added to the callback and defined for some platforms to selectively enable these safety features. The problem is that only certain platforms were given that software support. If the automotive safety package bit is set in the hardware features register the safety feature callback is called for the platform, and for platforms that didn't get a safety_feat_cfg defined this results in the following NULL pointer dereference: [ 7.933303] Call trace: [ 7.935812] dwmac5_safety_feat_config+0x20/0x170 [stmmac] [ 7.941455] __stmmac_open+0x16c/0x474 [stmmac] [ 7.946117] stmmac_open+0x38/0x70 [stmmac] [ 7.950414] __dev_open+0x100/0x1dc [ 7.954006] __dev_change_flags+0x18c/0x204 [ 7.958297] dev_change_flags+0x24/0x6c [ 7.962237] do_setlink+0x2b8/0xfa4 [ 7.965827] __rtnl_newlink+0x4ec/0x840 [ 7.969766] rtnl_newlink+0x50/0x80 [ 7.973353] rtnetlink_rcv_msg+0x12c/0x374 [ 7.977557] netlink_rcv_skb+0x5c/0x130 [ 7.981500] rtnetlink_rcv+0x18/0x2c [ 7.985172] netlink_unicast+0x2e8/0x340 [ 7.989197] netlink_sendmsg+0x1a8/0x420 [ 7.993222] ____sys_sendmsg+0x218/0x280 [ 7.997249] ___sys_sendmsg+0xac/0x100 [ 8.001103] __sys_sendmsg+0x84/0xe0 [ 8.004776] __arm64_sys_sendmsg+0x24/0x30 [ 8.008983] invoke_syscall+0x48/0x114 [ 8.012840] el0_svc_common.constprop.0+0xcc/0xec [ 8.017665] do_el0_svc+0x38/0xb0 [ 8.021071] el0_svc+0x2c/0x84 [ 8.024212] el0t_64_sync_handler+0xf4/0x120 [ 8.028598] el0t_64_sync+0x190/0x194 Go back to the original behavior, if the automotive safety package is found to be supported in hardware enable all the features unless safety_feat_cfg is passed in saying this particular platform only supports a subset of the features.
Modified: 2025-10-01
CVE-2023-53013
In the Linux kernel, the following vulnerability has been resolved: ptdma: pt_core_execute_cmd() should use spinlock The interrupt handler (pt_core_irq_handler()) of the ptdma driver can be called from interrupt context. The code flow in this function can lead down to pt_core_execute_cmd() which will attempt to grab a mutex, which is not appropriate in interrupt context and ultimately leads to a kernel panic. The fix here changes this mutex to a spinlock, which has been verified to resolve the issue.
Modified: 2025-10-01
CVE-2023-53015
In the Linux kernel, the following vulnerability has been resolved: HID: betop: check shape of output reports betopff_init() only checks the total sum of the report counts for each report field to be at least 4, but hid_betopff_play() expects 4 report fields. A device advertising an output report with one field and 4 report counts would pass the check but crash the kernel with a NULL pointer dereference in hid_betopff_play().
- https://git.kernel.org/stable/c/07bc32e53c7bd5c91472cc485231ef6274db9b76
- https://git.kernel.org/stable/c/1a2a47b85cab50a3c146731bfeaf2d860f5344ee
- https://git.kernel.org/stable/c/28fc6095da22dc88433d79578ae1c495ebe8ca43
- https://git.kernel.org/stable/c/3782c0d6edf658b71354a64d60aa7a296188fc90
- https://git.kernel.org/stable/c/7317326f685824c7c29bd80841fd18041af6bb73
- https://git.kernel.org/stable/c/d3065cc56221d1a5eda237e94eaf2a627b88ab79
- https://git.kernel.org/stable/c/dbab4dba400d6ea9a9697fbbd287adbf7db1dac4
Modified: 2025-10-01
CVE-2023-53016
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix possible deadlock in rfcomm_sk_state_change syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow: rfcomm_sock_connect: lock_sock(sk) rfcomm_dlc_open: rfcomm_lock() rfcomm_sock_release: rfcomm_sock_shutdown: rfcomm_lock() __rfcomm_dlc_close: rfcomm_k_state_change: lock_sock(sk) This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes.
Modified: 2025-10-30
CVE-2023-53019
In the Linux kernel, the following vulnerability has been resolved: net: mdio: validate parameter addr in mdiobus_get_phy() The caller may pass any value as addr, what may result in an out-of-bounds access to array mdio_map. One existing case is stmmac_init_phy() that may pass -1 as addr. Therefore validate addr before using it.
- https://git.kernel.org/stable/c/1d80c259dfbadefa61b7ea334dfce5cb57f8c72f
- https://git.kernel.org/stable/c/4bc5f1f6bc94e695dfd912122af96e7115a0ddb8
- https://git.kernel.org/stable/c/7879626296e6ffd838ae0f2af1ab49ee46354973
- https://git.kernel.org/stable/c/867dbe784c5010a466f00a7d1467c1c5ea569c75
- https://git.kernel.org/stable/c/8a7b9560a3a8eb8724888c426e05926752f73aa0
- https://git.kernel.org/stable/c/ad67de330d83e8078372b52af18ffe8d39e26c85
- https://git.kernel.org/stable/c/c431a3d642593bbdb99e8a9e3eed608b730db6f8
Modified: 2025-10-01
CVE-2023-53020
In the Linux kernel, the following vulnerability has been resolved: l2tp: close all race conditions in l2tp_tunnel_register() The code in l2tp_tunnel_register() is racy in several ways: 1. It modifies the tunnel socket _after_ publishing it. 2. It calls setup_udp_tunnel_sock() on an existing socket without locking. 3. It changes sock lock class on fly, which triggers many syzbot reports. This patch amends all of them by moving socket initialization code before publishing and under sock lock. As suggested by Jakub, the l2tp lockdep class is not necessary as we can just switch to bh_lock_sock_nested().
Modified: 2025-04-01
CVE-2023-53021
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_taprio: fix possible use-after-free syzbot reported a nasty crash [1] in net_tx_action() which made little sense until we got a repro. This repro installs a taprio qdisc, but providing an invalid TCA_RATE attribute. qdisc_create() has to destroy the just initialized taprio qdisc, and taprio_destroy() is called. However, the hrtimer used by taprio had already fired, therefore advance_sched() called __netif_schedule(). Then net_tx_action was trying to use a destroyed qdisc. We can not undo the __netif_schedule(), so we must wait until one cpu serviced the qdisc before we can proceed. Many thanks to Alexander Potapenko for his help. [1] BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline] BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline] BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline] BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline] do_raw_spin_trylock include/linux/spinlock.h:191 [inline] __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline] _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 spin_trylock include/linux/spinlock.h:359 [inline] qdisc_run_begin include/net/sch_generic.h:187 [inline] qdisc_run+0xee/0x540 include/net/pkt_sched.h:125 net_tx_action+0x77c/0x9a0 net/core/dev.c:5086 __do_softirq+0x1cc/0x7fb kernel/softirq.c:571 run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934 smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164 kthread+0x31b/0x430 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 Uninit was created at: slab_post_alloc_hook mm/slab.h:732 [inline] slab_alloc_node mm/slub.c:3258 [inline] __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970 kmalloc_reserve net/core/skbuff.c:358 [inline] __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430 alloc_skb include/linux/skbuff.h:1257 [inline] nlmsg_new include/net/netlink.h:953 [inline] netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436 netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507 rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536 __sys_sendmsg net/socket.c:2565 [inline] __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
- https://git.kernel.org/stable/c/1200388a0b1c3c6fda48d4d2143db8f7e4ef5348
- https://git.kernel.org/stable/c/3a415d59c1dbec9d772dbfab2d2520d98360caae
- https://git.kernel.org/stable/c/c53acbf2facfdfabdc6e6984a1a38f5d38b606a1
- https://git.kernel.org/stable/c/c60fe70078d6e515f424cb868d07e00411b27fbc
- https://git.kernel.org/stable/c/d3b2d2820a005e43855fa71b80c4a4b194201c60
Modified: 2025-10-01
CVE-2023-53022
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()
This lockdep splat says it better than I could:
================================
WARNING: inconsistent lock state
6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0
{IN-SOFTIRQ-W} state was registered at:
_raw_spin_lock+0x5c/0xc0
sch_direct_xmit+0x148/0x37c
__dev_queue_xmit+0x528/0x111c
ip6_finish_output2+0x5ec/0xb7c
ip6_finish_output+0x240/0x3f0
ip6_output+0x78/0x360
ndisc_send_skb+0x33c/0x85c
ndisc_send_rs+0x54/0x12c
addrconf_rs_timer+0x154/0x260
call_timer_fn+0xb8/0x3a0
__run_timers.part.0+0x214/0x26c
run_timer_softirq+0x3c/0x74
__do_softirq+0x14c/0x5d8
____do_softirq+0x10/0x20
call_on_irq_stack+0x2c/0x5c
do_softirq_own_stack+0x1c/0x30
__irq_exit_rcu+0x168/0x1a0
irq_exit_rcu+0x10/0x40
el1_interrupt+0x38/0x64
irq event stamp: 7825
hardirqs last enabled at (7825): [
Modified: 2025-04-01
CVE-2023-53023
In the Linux kernel, the following vulnerability has been resolved: net: nfc: Fix use-after-free in local_cleanup() Fix a use-after-free that occurs in kfree_skb() called from local_cleanup(). This could happen when killing nfc daemon (e.g. neard) after detaching an nfc device. When detaching an nfc device, local_cleanup() called from nfc_llcp_unregister_device() frees local->rx_pending and decreases local->ref by kref_put() in nfc_llcp_local_put(). In the terminating process, nfc daemon releases all sockets and it leads to decreasing local->ref. After the last release of local->ref, local_cleanup() called from local_release() frees local->rx_pending again, which leads to the bug. Setting local->rx_pending to NULL in local_cleanup() could prevent use-after-free when local_cleanup() is called twice. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in kfree_skb() Call Trace: dump_stack_lvl (lib/dump_stack.c:106) print_address_description.constprop.0.cold (mm/kasan/report.c:306) kasan_check_range (mm/kasan/generic.c:189) kfree_skb (net/core/skbuff.c:955) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172) nfc_llcp_local_put (net/nfc/llcp_core.c:181) llcp_sock_destruct (net/nfc/llcp_sock.c:959) __sk_destruct (net/core/sock.c:2133) sk_destruct (net/core/sock.c:2181) __sk_free (net/core/sock.c:2192) sk_free (net/core/sock.c:2203) llcp_sock_release (net/nfc/llcp_sock.c:646) __sock_release (net/socket.c:650) sock_close (net/socket.c:1365) __fput (fs/file_table.c:306) task_work_run (kernel/task_work.c:179) ptrace_notify (kernel/signal.c:2354) syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278) syscall_exit_to_user_mode (kernel/entry/common.c:296) do_syscall_64 (arch/x86/entry/common.c:86) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106) Allocated by task 4719: kasan_save_stack (mm/kasan/common.c:45) __kasan_slab_alloc (mm/kasan/common.c:325) slab_post_alloc_hook (mm/slab.h:766) kmem_cache_alloc_node (mm/slub.c:3497) __alloc_skb (net/core/skbuff.c:552) pn533_recv_response (drivers/nfc/pn533/usb.c:65) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671) usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704) tasklet_action_common.isra.0 (kernel/softirq.c:797) __do_softirq (kernel/softirq.c:571) Freed by task 1901: kasan_save_stack (mm/kasan/common.c:45) kasan_set_track (mm/kasan/common.c:52) kasan_save_free_info (mm/kasan/genericdd.c:518) __kasan_slab_free (mm/kasan/common.c:236) kmem_cache_free (mm/slub.c:3809) kfree_skbmem (net/core/skbuff.c:874) kfree_skb (net/core/skbuff.c:931) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617) nfc_unregister_device (net/nfc/core.c:1179) pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846) pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579) usb_unbind_interface (drivers/usb/core/driver.c:458) device_release_driver_internal (drivers/base/dd.c:1279) bus_remove_device (drivers/base/bus.c:529) device_del (drivers/base/core.c:3665) usb_disable_device (drivers/usb/core/message.c:1420) usb_disconnect (drivers/usb/core.c:2261) hub_event (drivers/usb/core/hub.c:5833) process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281) worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423) kthread (kernel/kthread.c:319) ret_from_fork (arch/x86/entry/entry_64.S:301)
- https://git.kernel.org/stable/c/4bb4db7f3187c6e3de6b229ffc87cdb30a2d22b6
- https://git.kernel.org/stable/c/54f7be61584b8ec4c6df405f479495b9397bae4a
- https://git.kernel.org/stable/c/7f129927feaf7c10b1c38bbce630172e9a08c834
- https://git.kernel.org/stable/c/a59cdbda3714e11aa3ab579132864c4c8c6d54f9
- https://git.kernel.org/stable/c/ad1baab3a5c03692d22ce446f38596a126377f6a
- https://git.kernel.org/stable/c/b09ae26f08aaf2d85f96ea7f90ddd3387f62216f
- https://git.kernel.org/stable/c/d3605282ec3502ec8847915eb2cf1f340493ff79
Modified: 2026-01-22
CVE-2023-53024
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation") inserts lfence instructions after 1) initializing a stack slot and 2) spilling a pointer to the stack. However, this does not cover cases where a stack slot is first initialized with a pointer (subject to sanitization) but then overwritten with a scalar (not subject to sanitization because the slot was already initialized). In this case, the second write may be subject to speculative store bypass (SSB) creating a speculative pointer-as-scalar type confusion. This allows the program to subsequently leak the numerical pointer value using, for example, a branch-based cache side channel. To fix this, also sanitize scalars if they write a stack slot that previously contained a pointer. Assuming that pointer-spills are only generated by LLVM on register-pressure, the performance impact on most real-world BPF programs should be small. The following unprivileged BPF bytecode drafts a minimal exploit and the mitigation: [...] // r6 = 0 or 1 (skalar, unknown user input) // r7 = accessible ptr for side channel // r10 = frame pointer (fp), to be leaked // r9 = r10 # fp alias to encourage ssb *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked // lfence added here because of pointer spill to stack. // // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor // for no r9-r10 dependency. // *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID, // store may be subject to SSB // // fix: also add an lfence when the slot contained a ptr // r8 = *(u64 *)(r9 - 8) // r8 = architecturally a scalar, speculatively a ptr // // leak ptr using branch-based cache side channel: r8 &= 1 // choose bit to leak if r8 == 0 goto SLOW // no mispredict // architecturally dead code if input r6 is 0, // only executes speculatively iff ptr bit is 1 r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast) SLOW: [...] After running this, the program can time the access to *(r7 + 0) to determine whether the chosen pointer bit was 0 or 1. Repeat this 64 times to recover the whole address on amd64. In summary, sanitization can only be skipped if one scalar is overwritten with another scalar. Scalar-confusion due to speculative store bypass can not lead to invalid accesses because the pointer bounds deducted during verification are enforced using branchless logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") for details. Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks} because speculative leaks are likely unexpected if these were enabled. For example, leaking the address to a protected log file may be acceptable while disabling the mitigation might unintentionally leak the address into the cached-state of a map that is accessible to unprivileged processes.
- https://git.kernel.org/stable/c/01bdcc73dbe7be3ad4d4ee9a59b71e42f461a528
- https://git.kernel.org/stable/c/81b3374944d201872cfcf82730a7860f8e7c31dd
- https://git.kernel.org/stable/c/aae109414a57ab4164218f36e2e4a17f027fcaaa
- https://git.kernel.org/stable/c/b0c89ef025562161242a7c19b213bd6b272e93df
- https://git.kernel.org/stable/c/da75dec7c6617bddad418159ffebcb133f008262
- https://git.kernel.org/stable/c/e4f4db47794c9f474b184ee1418f42e6a07412b6
Modified: 2025-10-01
CVE-2023-53026
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix ib block iterator counter overflow When registering a new DMA MR after selecting the best aligned page size for it, we iterate over the given sglist to split each entry to smaller, aligned to the selected page size, DMA blocks. In given circumstances where the sg entry and page size fit certain sizes and the sg entry is not aligned to the selected page size, the total size of the aligned pages we need to cover the sg entry is >= 4GB. Under this circumstances, while iterating page aligned blocks, the counter responsible for counting how much we advanced from the start of the sg entry is overflowed because its type is u32 and we pass 4GB in size. This can lead to an infinite loop inside the iterator function because the overflow prevents the counter to be larger than the size of the sg entry. Fix the presented problem by changing the advancement condition to eliminate overflow. Backtrace: [ 192.374329] efa_reg_user_mr_dmabuf [ 192.376783] efa_register_mr [ 192.382579] pgsz_bitmap 0xfffff000 rounddown 0x80000000 [ 192.386423] pg_sz [0x80000000] umem_length[0xc0000000] [ 192.392657] start 0x0 length 0xc0000000 params.page_shift 31 params.page_num 3 [ 192.399559] hp_cnt[3], pages_in_hp[524288] [ 192.403690] umem->sgt_append.sgt.nents[1] [ 192.407905] number entries: [1], pg_bit: [31] [ 192.411397] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.415601] biter->__sg_advance [665837568] sg_dma_len[3221225472] [ 192.419823] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.423976] biter->__sg_advance [2813321216] sg_dma_len[3221225472] [ 192.428243] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.432397] biter->__sg_advance [665837568] sg_dma_len[3221225472]
- https://git.kernel.org/stable/c/0afec5e9cea732cb47014655685a2a47fb180c31
- https://git.kernel.org/stable/c/362c9489720b31b6aa7491423ba65a4e98aa9838
- https://git.kernel.org/stable/c/43811d07ea64366af8ec9e168c558ec51440c39e
- https://git.kernel.org/stable/c/902063a9fea5f8252df392ade746bc9cfd07a5ae
- https://git.kernel.org/stable/c/d66c1d4178c219b6e7d7a6f714e3e3656faccc36
Modified: 2025-10-31
CVE-2023-53031
In the Linux kernel, the following vulnerability has been resolved:
powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP
and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.
Command to trigger the warning:
# perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5
Performance counter stats for 'sleep 5':
0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/
5.002117947 seconds time elapsed
0.000131000 seconds user
0.001063000 seconds sys
Below is snippet of the warning in dmesg:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec
preempt_count: 2, expected: 0
4 locks held by perf-exec/2869:
#0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90
#1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0
#2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510
#3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510
irq event stamp: 4806
hardirqs last enabled at (4805): [
- https://git.kernel.org/stable/c/424bcb570cb320d1d15238cd4c933522b90f78fa
- https://git.kernel.org/stable/c/76d588dddc459fefa1da96e0a081a397c5c8e216
- https://git.kernel.org/stable/c/8cbeb60320ac45a8240b561c8ef466b86c34dedc
- https://git.kernel.org/stable/c/a90d339f1f66be4a946769b565668e2bd0686dfa
- https://git.kernel.org/stable/c/d0c6d2a31026102d4738b47a610bed4401b9834f
Modified: 2025-10-31
CVE-2023-53032
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function. When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value of an arithmetic expression 2 << (netmask - mask_bits - 1) is subject to overflow due to a failure casting operands to a larger data type before performing the arithmetic. Note that it's harmless since the value will be checked at the next step. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/4e6a70fd840400e3a2e784a6673968a3eb2431c0
- https://git.kernel.org/stable/c/511cf17b2447fc41cfef8d71936e1fa53e395c1e
- https://git.kernel.org/stable/c/9ea4b476cea1b7d461d16dda25ca3c7e616e2d15
- https://git.kernel.org/stable/c/dfd834ccc1b88bbbab81b9046a3a539dd0c2d14f
- https://git.kernel.org/stable/c/e137d9bb26bd85ce07323a38e38ceb0b160db841
- https://git.kernel.org/stable/c/e88865876d47c790be0d5e23973499d75d034364
- https://git.kernel.org/stable/c/feefb33eefa166fc3e0fd17547b0bc0cb3baced9
Modified: 2025-10-31
CVE-2023-53033
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: incorrect arithmetics when fetching VLAN header bits If the offset + length goes over the ethernet + vlan header, then the length is adjusted to copy the bytes that are within the boundaries of the vlan_ethhdr scratchpad area. The remaining bytes beyond ethernet + vlan header are copied directly from the skbuff data area. Fix incorrect arithmetic operator: subtract, not add, the size of the vlan header in case of double-tagged packets to adjust the length accordingly to address CVE-2023-0179.
Modified: 2025-11-24
CVE-2023-53163
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: don't hold ni_lock when calling truncate_setsize() syzbot is reporting hung task at do_user_addr_fault() [1], for there is a silent deadlock between PG_locked bit and ni_lock lock. Since filemap_update_page() calls filemap_read_folio() after calling folio_trylock() which will set PG_locked bit, ntfs_truncate() must not call truncate_setsize() which will wait for PG_locked bit to be cleared when holding ni_lock lock.
Modified: 2026-01-14
CVE-2023-53330
In the Linux kernel, the following vulnerability has been resolved: caif: fix memory leak in cfctrl_linkup_request() When linktype is unknown or kzalloc failed in cfctrl_linkup_request(), pkt is not released. Add release process to error path.
- https://git.kernel.org/stable/c/1dddeceb26002cfea4c375e92ac6498768dc7349
- https://git.kernel.org/stable/c/33df9c5d5e2a18c70f5f5f3c2757d654c1b6ffa3
- https://git.kernel.org/stable/c/3acf3783a84cbdf0c9f8cf2f32ee9c49af93a2da
- https://git.kernel.org/stable/c/3ad47c8aa5648226184415e4a0cb1bf67ffbfd48
- https://git.kernel.org/stable/c/84b2cc7b36b7f6957d307fb3d01603f93cb2d655
- https://git.kernel.org/stable/c/badea57569db04b010e922e29a7aaf40a979a70b
- https://git.kernel.org/stable/c/dc1bc903970bdf63ca40ab923d3ccb765da9a8d9
- https://git.kernel.org/stable/c/fe69230f05897b3de758427b574fc98025dfc907
Modified: 2026-01-14
CVE-2023-53393
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device
Currently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0),
there is a special handling in order to use the correct counters, but,
port_num is being passed down the stack without any change. Also, some
functions assume that port_num >=1. As a result, the following oops can
occur.
BUG: unable to handle page fault for address: ffff89510294f1a8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP
CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:_raw_spin_lock+0xc/0x20
Call Trace:
Modified: 2026-03-23
CVE-2023-53549
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Rework long task execution when adding/deleting entries When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete") tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step. The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel.
- https://git.kernel.org/stable/c/24a828f5a54bdeca0846526860d72b3766c5fe95
- https://git.kernel.org/stable/c/5e29dc36bd5e2166b834ceb19990d9e68a734d7d
- https://git.kernel.org/stable/c/8964cc36ba011dc0e1041131fa2e91fb4c2a811b
- https://git.kernel.org/stable/c/a1e1521b463968b4eca7163f61fb6cc54d008061
- https://git.kernel.org/stable/c/ee756980e491c829ba0495bb420b7224a9ee26b2
Modified: 2026-03-21
CVE-2023-53592
In the Linux kernel, the following vulnerability has been resolved: gpio: sifive: Fix refcount leak in sifive_gpio_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/694175cd8a1643cde3acb45c9294bca44a8e08e9
- https://git.kernel.org/stable/c/95da1882ce9372ba20278f87cdb7a34f9812c4b5
- https://git.kernel.org/stable/c/9a402a210798662b04cbe6ca466e916a15efa03a
- https://git.kernel.org/stable/c/f4a2ad1002006548e235255c65a4f1d07312be9d
- https://git.kernel.org/stable/c/f9fb4776ebbc16dfc512adbdc0fe218acb47c7cc
Modified: 2026-02-05
CVE-2023-53625
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gvt: fix vgpu debugfs clean in remove
Check carefully on root debugfs available when destroying vgpu,
e.g in remove case drm minor's debugfs root might already be destroyed,
which led to kernel oops like below.
Console: switching to colour dummy device 80x25
i915 0000:00:02.0: MDEV: Unregistering
intel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14
BUG: kernel NULL pointer dereference, address: 0000000000000150
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6
Hardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022
RIP: 0010:__lock_acquire+0x5e2/0x1f90
Code: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff <48> 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0
RSP: 0018:ffff9f770274f948 EFLAGS: 00010046
RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000
R13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000
FS: 00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/44c0e07e3972e3f2609d69ad873d4f342f8a68ec
- https://git.kernel.org/stable/c/704f3384f322b40ba24d958473edfb1c9750c8fd
- https://git.kernel.org/stable/c/af90f8b36d78544433a48a3eda6a5faeafacd0a1
- https://git.kernel.org/stable/c/f5a9bbf962e2c4b1d9addbfaf16d7ffcc2f63bde
- https://git.kernel.org/stable/c/ffa83fba2a2ce8010eb106c779378cb3013362c7
Modified: 2025-11-03
CVE-2025-21726
In the Linux kernel, the following vulnerability has been resolved:
padata: avoid UAF for reorder_work
Although the previous patch can avoid ps and ps UAF for _do_serial, it
can not avoid potential UAF issue for reorder_work. This issue can
happen just as below:
crypto_request crypto_request crypto_del_alg
padata_do_serial
...
padata_reorder
// processes all remaining
// requests then breaks
while (1) {
if (!padata)
break;
...
}
padata_do_serial
// new request added
list_add
// sees the new request
queue_work(reorder_work)
padata_reorder
queue_work_on(squeue->work)
...
- https://git.kernel.org/stable/c/4c6209efea2208597dbd3e52dc87a0d1a8f2dbe1
- https://git.kernel.org/stable/c/6f45ef616775b0ce7889b0f6077fc8d681ab30bc
- https://git.kernel.org/stable/c/7000507bb0d2ceb545c0a690e0c707c897d102c2
- https://git.kernel.org/stable/c/8ca38d0ca8c3d30dd18d311f1a7ec5cb56972cac
- https://git.kernel.org/stable/c/a54091c24220a4cd847d5b4f36d678edacddbaf0
- https://git.kernel.org/stable/c/dd7d37ccf6b11f3d95e797ebe4e9e886d0332600
- https://git.kernel.org/stable/c/f4f1b1169fc3694f9bc3e28c6c68dbbf4cc744c0
- https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Closed vulnerabilities
Modified: 2024-08-26
BDU:2020-00692
Уязвимость компонента Active Directory LDAP-сервера программ сетевого взаимодействия Samba, позволяющая нарушителю получить несанкционированный доступ к конфиденциальным данным
Modified: 2025-03-05
BDU:2023-02011
Уязвимость утилиты samba-tool пакета программ сетевого взаимодействия Samba, позволяющая нарушителю получить несанкционированный доступ к устройству
Modified: 2025-03-05
BDU:2023-02012
Уязвимость пакета программ сетевого взаимодействия Samba, связанная с отсутствием защиты служебных данных, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-11-11
BDU:2023-02013
Уязвимость LDAP-сервера пакета программ сетевого взаимодействия Samba, позволяющая нарушителю удалить атрибут DNS-Host-Name из любого объекта в каталоге
Modified: 2024-11-11
BDU:2023-03963
Уязвимость компонента winbindd_pam_auth_crap.c пакета программ сетевого взаимодействия Samba, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2023-04385
Уязвимость функции sl_unpack_loop() службы mdssvc RPC пакета программ сетевого взаимодействия Samba, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-08
BDU:2023-06939
Уязвимость RPC-сервера пакета программ сетевого взаимодействия Samba, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2023-06940
Уязвимость функции dcesrv_echo_TestSleep() RPC-сервера rpcecho пакета программ сетевого взаимодействия Samba, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2023-06941
Уязвимость модуля VFS пакета программ сетевого взаимодействия Samba, позволяющая нарушителю получить доступ на чтение, изменение или удаление файлов
Modified: 2025-06-03
BDU:2023-06942
Уязвимость механизма синхронизации катологов DirSync пакета программ сетевого взаимодействия Samba, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации и повысить свои привилегии
Modified: 2024-11-26
BDU:2023-07174
Уязвимость библиотеки smbd пакета программ сетевого взаимодействия Samba, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2023-09090
Уязвимость пакета программ сетевого взаимодействия Samba, связанная с настройками прав доступа по умолчанию, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2025-01-29
BDU:2023-09107
Уязвимость функции dalloc_value_for_key() пакета программ сетевого взаимодействия Samba, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-08-26
BDU:2024-01904
Уязвимость механизма подписи пакетов SMB2 пакета программ сетевого взаимодействия Samba, позволяющая нарушителю реализовать атаку типа «человек посередине»
Modified: 2024-11-26
BDU:2024-06935
Уязвимость пакета программ сетевого взаимодействия Samba, связанная с раскрытием информации, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2025-10-07
BDU:2024-06955
Уязвимость функции gnutls_rnd() пакета программ сетевого взаимодействия Samba, связанная с использованием недостаточно случайных значений, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2025-09-24
BDU:2025-00114
Уязвимость реализации протокола LDAP пакета программ сетевого взаимодействия Samba, позволяющая нарушителю повысить свои привилегии
Modified: 2026-03-04
BDU:2025-03903
Уязвимость пакета программ сетевого взаимодействия Samba, связанная с ошибками авторизации, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2024-11-21
CVE-2018-10919
The Samba Active Directory LDAP server was vulnerable to an information disclosure flaw because of missing access control checks. An authenticated attacker could use this flaw to extract confidential attribute values using LDAP search expressions. Samba versions before 4.6.16, 4.7.9 and 4.8.4 are vulnerable.
- http://www.securityfocus.com/bid/105081
- https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10919
- https://security.gentoo.org/glsa/202003-52
- https://security.netapp.com/advisory/ntap-20180814-0001/
- https://usn.ubuntu.com/3738-1/
- https://www.debian.org/security/2018/dsa-4271
- https://www.samba.org/samba/security/CVE-2018-10919.html
- http://www.securityfocus.com/bid/105081
- https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10919
- https://security.gentoo.org/glsa/202003-52
- https://security.netapp.com/advisory/ntap-20180814-0001/
- https://usn.ubuntu.com/3738-1/
- https://www.debian.org/security/2018/dsa-4271
- https://www.samba.org/samba/security/CVE-2018-10919.html
Modified: 2025-01-22
CVE-2018-14628
An information leak vulnerability was discovered in Samba's LDAP server. Due to missing access control checks, an authenticated but unprivileged attacker could discover the names and preserved attributes of deleted objects in the LDAP store.
- http://www.openwall.com/lists/oss-security/2023/11/28/4
- https://bugzilla.redhat.com/show_bug.cgi?id=1625445
- https://bugzilla.samba.org/show_bug.cgi?id=13595
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6DK57HQRTCDOZDIIICYWQ4Z5IQXTWVVW/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ACVMYEP5KJRL3FWSCZW2MQZ26IVPXY62/
- http://www.openwall.com/lists/oss-security/2023/11/28/4
- https://bugzilla.redhat.com/show_bug.cgi?id=1625445
- https://bugzilla.samba.org/show_bug.cgi?id=13595
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6DK57HQRTCDOZDIIICYWQ4Z5IQXTWVVW/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ACVMYEP5KJRL3FWSCZW2MQZ26IVPXY62/
- https://security.netapp.com/advisory/ntap-20230223-0008/
Modified: 2026-04-27
CVE-2020-25720
A vulnerability was found in Samba where a delegated administrator with permission to create objects in Active Directory can write to all attributes of the newly created object, including security-sensitive attributes, even after the object's creation. This issue occurs because the administrator owns the object due to the lack of an Access Control List (ACL) at the time of creation and later being recognized as the 'creator owner.' The retained significant rights of the delegated administrator may not be well understood, potentially leading to unintended privilege escalation or security risks.
Modified: 2025-08-22
CVE-2022-1615
In Samba, GnuTLS gnutls_rnd() can fail and give predictable random values.
- https://bugzilla.samba.org/show_bug.cgi?id=15103
- https://gitlab.com/samba-team/samba/-/merge_requests/2644
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZTTOLTHUHOV4SHCHCB5TAA4FQVJAWN4P/
- https://security.gentoo.org/glsa/202309-06
- https://bugzilla.samba.org/show_bug.cgi?id=15103
- https://gitlab.com/samba-team/samba/-/merge_requests/2644
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZTTOLTHUHOV4SHCHCB5TAA4FQVJAWN4P/
- https://security.gentoo.org/glsa/202309-06
Modified: 2024-11-21
CVE-2022-2127
An out-of-bounds read vulnerability was found in Samba due to insufficient length checks in winbindd_pam_auth_crap.c. When performing NTLM authentication, the client replies to cryptographic challenges back to the server. These replies have variable lengths, and Winbind fails to check the lan manager response length. When Winbind is used for NTLM authentication, a maliciously crafted request can trigger an out-of-bounds read in Winbind, possibly resulting in a crash.
- https://access.redhat.com/errata/RHSA-2023:6667
- https://access.redhat.com/errata/RHSA-2023:7139
- https://access.redhat.com/errata/RHSA-2024:0423
- https://access.redhat.com/errata/RHSA-2024:0580
- https://access.redhat.com/security/cve/CVE-2022-2127
- https://bugzilla.redhat.com/show_bug.cgi?id=2222791
- https://www.samba.org/samba/security/CVE-2022-2127.html
- https://access.redhat.com/errata/RHSA-2023:6667
- https://access.redhat.com/errata/RHSA-2023:7139
- https://access.redhat.com/errata/RHSA-2024:0423
- https://access.redhat.com/errata/RHSA-2024:0580
- https://access.redhat.com/security/cve/CVE-2022-2127
- https://bugzilla.redhat.com/show_bug.cgi?id=2222791
- https://lists.debian.org/debian-lts-announce/2024/04/msg00015.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BPCSGND7LO467AJGR5DYBGZLTCGTOBCC/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OT74M42E6C36W7PQVY3OS4ZM7DVYB64Z/
- https://security.netapp.com/advisory/ntap-20230731-0010/
- https://www.debian.org/security/2023/dsa-5477
- https://www.samba.org/samba/security/CVE-2022-2127.html
Modified: 2025-08-22
CVE-2022-32743
Samba does not validate the Validated-DNS-Host-Name right for the dNSHostName attribute which could permit unprivileged users to write it.
- https://bugzilla.samba.org/show_bug.cgi?id=14833
- https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/5c578b15-d619-408d-ba17-380714b89fd1
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZTTOLTHUHOV4SHCHCB5TAA4FQVJAWN4P/
- https://security.gentoo.org/glsa/202309-06
- https://bugzilla.samba.org/show_bug.cgi?id=14833
- https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/5c578b15-d619-408d-ba17-380714b89fd1
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZTTOLTHUHOV4SHCHCB5TAA4FQVJAWN4P/
- https://security.gentoo.org/glsa/202309-06
Modified: 2025-02-18
CVE-2023-0225
A flaw was found in Samba. An incomplete access check on dnsHostName allows authenticated but otherwise unprivileged users to delete this attribute from any object in the directory.
- https://security.gentoo.org/glsa/202309-06
- https://security.netapp.com/advisory/ntap-20230406-0007/
- https://www.samba.org/samba/security/CVE-2023-0225.html
- https://security.gentoo.org/glsa/202309-06
- https://security.netapp.com/advisory/ntap-20230406-0007/
- https://www.samba.org/samba/security/CVE-2023-0225.html
Modified: 2025-02-13
CVE-2023-0614
The fix in 4.6.16, 4.7.9, 4.8.4 and 4.9.7 for CVE-2018-10919 Confidential attribute disclosure vi LDAP filters was insufficient and an attacker may be able to obtain confidential BitLocker recovery keys from a Samba AD DC.
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YXBPYIA4VWNOD437NAHZ3NXKAETLFB5S/
- https://security.gentoo.org/glsa/202309-06
- https://security.netapp.com/advisory/ntap-20230406-0007/
- https://www.samba.org/samba/security/CVE-2023-0614.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YXBPYIA4VWNOD437NAHZ3NXKAETLFB5S/
- https://security.gentoo.org/glsa/202309-06
- https://security.netapp.com/advisory/ntap-20230406-0007/
- https://www.samba.org/samba/security/CVE-2023-0614.html
Modified: 2025-02-13
CVE-2023-0922
The Samba AD DC administration tool, when operating against a remote LDAP server, will by default send new or reset passwords over a signed-only connection.
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YXBPYIA4VWNOD437NAHZ3NXKAETLFB5S/
- https://security.gentoo.org/glsa/202309-06
- https://security.netapp.com/advisory/ntap-20230406-0007/
- https://www.samba.org/samba/security/CVE-2023-0922.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YXBPYIA4VWNOD437NAHZ3NXKAETLFB5S/
- https://security.gentoo.org/glsa/202309-06
- https://security.netapp.com/advisory/ntap-20230406-0007/
- https://www.samba.org/samba/security/CVE-2023-0922.html
Modified: 2024-12-06
CVE-2023-3347
A vulnerability was found in Samba's SMB2 packet signing mechanism. The SMB2 packet signing is not enforced if an admin configured "server signing = required" or for SMB2 connections to Domain Controllers where SMB2 packet signing is mandatory. This flaw allows an attacker to perform attacks, such as a man-in-the-middle attack, by intercepting the network traffic and modifying the SMB2 messages between client and server, affecting the integrity of the data.
- https://access.redhat.com/errata/RHSA-2023:4325
- https://access.redhat.com/errata/RHSA-2023:4328
- https://access.redhat.com/security/cve/CVE-2023-3347
- https://bugzilla.redhat.com/show_bug.cgi?id=2222792
- https://www.samba.org/samba/security/CVE-2023-3347.html
- https://access.redhat.com/errata/RHSA-2023:4325
- https://access.redhat.com/errata/RHSA-2023:4328
- https://access.redhat.com/security/cve/CVE-2023-3347
- https://bugzilla.redhat.com/show_bug.cgi?id=2222792
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BPCSGND7LO467AJGR5DYBGZLTCGTOBCC/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OT74M42E6C36W7PQVY3OS4ZM7DVYB64Z/
- https://security.netapp.com/advisory/ntap-20230731-0010/
- https://www.debian.org/security/2023/dsa-5477
- https://www.samba.org/samba/security/CVE-2023-3347.html
Modified: 2024-11-21
CVE-2023-34966
An infinite loop vulnerability was found in Samba's mdssvc RPC service for Spotlight. When parsing Spotlight mdssvc RPC packets sent by the client, the core unmarshalling function sl_unpack_loop() did not validate a field in the network packet that contains the count of elements in an array-like structure. By passing 0 as the count value, the attacked function will run in an endless loop consuming 100% CPU. This flaw allows an attacker to issue a malformed RPC request, triggering an infinite loop, resulting in a denial of service condition.
- https://access.redhat.com/errata/RHSA-2023:6667
- https://access.redhat.com/errata/RHSA-2023:7139
- https://access.redhat.com/errata/RHSA-2024:0423
- https://access.redhat.com/errata/RHSA-2024:0580
- https://access.redhat.com/errata/RHSA-2024:4101
- https://access.redhat.com/security/cve/CVE-2023-34966
- https://bugzilla.redhat.com/show_bug.cgi?id=2222793
- https://www.samba.org/samba/security/CVE-2023-34966
- https://access.redhat.com/errata/RHSA-2023:6667
- https://access.redhat.com/errata/RHSA-2023:7139
- https://access.redhat.com/errata/RHSA-2024:0423
- https://access.redhat.com/errata/RHSA-2024:0580
- https://access.redhat.com/errata/RHSA-2024:4101
- https://access.redhat.com/security/cve/CVE-2023-34966
- https://bugzilla.redhat.com/show_bug.cgi?id=2222793
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BPCSGND7LO467AJGR5DYBGZLTCGTOBCC/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OT74M42E6C36W7PQVY3OS4ZM7DVYB64Z/
- https://security.netapp.com/advisory/ntap-20230731-0010/
- https://www.debian.org/security/2023/dsa-5477
- https://www.samba.org/samba/security/CVE-2023-34966
Modified: 2024-11-21
CVE-2023-34967
A Type Confusion vulnerability was found in Samba's mdssvc RPC service for Spotlight. When parsing Spotlight mdssvc RPC packets, one encoded data structure is a key-value style dictionary where the keys are character strings, and the values can be any of the supported types in the mdssvc protocol. Due to a lack of type checking in callers of the dalloc_value_for_key() function, which returns the object associated with a key, a caller may trigger a crash in talloc_get_size() when talloc detects that the passed-in pointer is not a valid talloc pointer. With an RPC worker process shared among multiple client connections, a malicious client or attacker can trigger a process crash in a shared RPC mdssvc worker process, affecting all other clients this worker serves.
- https://access.redhat.com/errata/RHSA-2023:6667
- https://access.redhat.com/errata/RHSA-2023:7139
- https://access.redhat.com/errata/RHSA-2024:0423
- https://access.redhat.com/errata/RHSA-2024:0580
- https://access.redhat.com/security/cve/CVE-2023-34967
- https://bugzilla.redhat.com/show_bug.cgi?id=2222794
- https://www.samba.org/samba/security/CVE-2023-34967.html
- https://access.redhat.com/errata/RHSA-2023:6667
- https://access.redhat.com/errata/RHSA-2023:7139
- https://access.redhat.com/errata/RHSA-2024:0423
- https://access.redhat.com/errata/RHSA-2024:0580
- https://access.redhat.com/security/cve/CVE-2023-34967
- https://bugzilla.redhat.com/show_bug.cgi?id=2222794
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BPCSGND7LO467AJGR5DYBGZLTCGTOBCC/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OT74M42E6C36W7PQVY3OS4ZM7DVYB64Z/
- https://security.netapp.com/advisory/ntap-20230731-0010/
- https://www.debian.org/security/2023/dsa-5477
- https://www.samba.org/samba/security/CVE-2023-34967.html
Modified: 2024-12-06
CVE-2023-34968
A path disclosure vulnerability was found in Samba. As part of the Spotlight protocol, Samba discloses the server-side absolute path of shares, files, and directories in the results for search queries. This flaw allows a malicious client or an attacker with a targeted RPC request to view the information that is part of the disclosed path.
- https://access.redhat.com/errata/RHSA-2023:6667
- https://access.redhat.com/errata/RHSA-2023:7139
- https://access.redhat.com/errata/RHSA-2024:0423
- https://access.redhat.com/errata/RHSA-2024:0580
- https://access.redhat.com/security/cve/CVE-2023-34968
- https://bugzilla.redhat.com/show_bug.cgi?id=2222795
- https://www.samba.org/samba/security/CVE-2023-34968.html
- https://access.redhat.com/errata/RHSA-2023:6667
- https://access.redhat.com/errata/RHSA-2023:7139
- https://access.redhat.com/errata/RHSA-2024:0423
- https://access.redhat.com/errata/RHSA-2024:0580
- https://access.redhat.com/security/cve/CVE-2023-34968
- https://bugzilla.redhat.com/show_bug.cgi?id=2222795
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BPCSGND7LO467AJGR5DYBGZLTCGTOBCC/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OT74M42E6C36W7PQVY3OS4ZM7DVYB64Z/
- https://security.netapp.com/advisory/ntap-20230731-0010/
- https://www.debian.org/security/2023/dsa-5477
- https://www.samba.org/samba/security/CVE-2023-34968.html
Modified: 2024-11-21
CVE-2023-3961
A path traversal vulnerability was identified in Samba when processing client pipe names connecting to Unix domain sockets within a private directory. Samba typically uses this mechanism to connect SMB clients to remote procedure call (RPC) services like SAMR LSA or SPOOLSS, which Samba initiates on demand. However, due to inadequate sanitization of incoming client pipe names, allowing a client to send a pipe name containing Unix directory traversal characters (../). This could result in SMB clients connecting as root to Unix domain sockets outside the private directory. If an attacker or client managed to send a pipe name resolving to an external service using an existing Unix domain socket, it could potentially lead to unauthorized access to the service and consequential adverse events, including compromise or service crashes.
- https://access.redhat.com/errata/RHSA-2023:6209
- https://access.redhat.com/errata/RHSA-2023:6744
- https://access.redhat.com/errata/RHSA-2023:7371
- https://access.redhat.com/errata/RHSA-2023:7408
- https://access.redhat.com/errata/RHSA-2023:7464
- https://access.redhat.com/errata/RHSA-2023:7467
- https://access.redhat.com/security/cve/CVE-2023-3961
- https://bugzilla.redhat.com/show_bug.cgi?id=2241881
- https://bugzilla.samba.org/show_bug.cgi?id=15422
- https://www.samba.org/samba/security/CVE-2023-3961.html
- https://access.redhat.com/errata/RHSA-2023:6209
- https://access.redhat.com/errata/RHSA-2023:6744
- https://access.redhat.com/errata/RHSA-2023:7371
- https://access.redhat.com/errata/RHSA-2023:7408
- https://access.redhat.com/errata/RHSA-2023:7464
- https://access.redhat.com/errata/RHSA-2023:7467
- https://access.redhat.com/security/cve/CVE-2023-3961
- https://bugzilla.redhat.com/show_bug.cgi?id=2241881
- https://bugzilla.samba.org/show_bug.cgi?id=15422
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZUMVALLFFDFC53JZMUWA6HPD7HUGAP5I/
- https://security.netapp.com/advisory/ntap-20231124-0002/
- https://www.samba.org/samba/security/CVE-2023-3961.html
Modified: 2024-11-21
CVE-2023-4091
A vulnerability was discovered in Samba, where the flaw allows SMB clients to truncate files, even with read-only permissions when the Samba VFS module "acl_xattr" is configured with "acl_xattr:ignore system acls = yes". The SMB protocol allows opening files when the client requests read-only access but then implicitly truncates the opened file to 0 bytes if the client specifies a separate OVERWRITE create disposition request. The issue arises in configurations that bypass kernel file system permissions checks, relying solely on Samba's permissions.
- https://access.redhat.com/errata/RHSA-2023:6209
- https://access.redhat.com/errata/RHSA-2023:6744
- https://access.redhat.com/errata/RHSA-2023:7371
- https://access.redhat.com/errata/RHSA-2023:7408
- https://access.redhat.com/errata/RHSA-2023:7464
- https://access.redhat.com/errata/RHSA-2023:7467
- https://access.redhat.com/security/cve/CVE-2023-4091
- https://bugzilla.redhat.com/show_bug.cgi?id=2241882
- https://bugzilla.samba.org/show_bug.cgi?id=15439
- https://www.samba.org/samba/security/CVE-2023-4091.html
- https://access.redhat.com/errata/RHSA-2023:6209
- https://access.redhat.com/errata/RHSA-2023:6744
- https://access.redhat.com/errata/RHSA-2023:7371
- https://access.redhat.com/errata/RHSA-2023:7408
- https://access.redhat.com/errata/RHSA-2023:7464
- https://access.redhat.com/errata/RHSA-2023:7467
- https://access.redhat.com/security/cve/CVE-2023-4091
- https://bugzilla.redhat.com/show_bug.cgi?id=2241882
- https://bugzilla.samba.org/show_bug.cgi?id=15439
- https://lists.debian.org/debian-lts-announce/2024/04/msg00015.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZUMVALLFFDFC53JZMUWA6HPD7HUGAP5I/
- https://security.netapp.com/advisory/ntap-20231124-0002/
- https://www.samba.org/samba/security/CVE-2023-4091.html
Modified: 2024-11-21
CVE-2023-4154
A design flaw was found in Samba's DirSync control implementation, which exposes passwords and secrets in Active Directory to privileged users and Read-Only Domain Controllers (RODCs). This flaw allows RODCs and users possessing the GET_CHANGES right to access all attributes, including sensitive secrets and passwords. Even in a default setup, RODC DC accounts, which should only replicate some passwords, can gain access to all domain secrets, including the vital krbtgt, effectively eliminating the RODC / DC distinction. Furthermore, the vulnerability fails to account for error conditions (fail open), like out-of-memory situations, potentially granting access to secret attributes, even under low-privileged attacker influence.
- https://access.redhat.com/security/cve/CVE-2023-4154
- https://bugzilla.redhat.com/show_bug.cgi?id=2241883
- https://bugzilla.samba.org/show_bug.cgi?id=15424
- https://security.netapp.com/advisory/ntap-20231124-0002/
- https://www.samba.org/samba/security/CVE-2023-4154.html
- https://access.redhat.com/security/cve/CVE-2023-4154
- https://bugzilla.redhat.com/show_bug.cgi?id=2241883
- https://bugzilla.samba.org/show_bug.cgi?id=15424
- https://security.netapp.com/advisory/ntap-20231124-0002/
- https://www.samba.org/samba/security/CVE-2023-4154.html
Modified: 2024-11-21
CVE-2023-42669
A vulnerability was found in Samba's "rpcecho" development server, a non-Windows RPC server used to test Samba's DCE/RPC stack elements. This vulnerability stems from an RPC function that can be blocked indefinitely. The issue arises because the "rpcecho" service operates with only one worker in the main RPC task, allowing calls to the "rpcecho" server to be blocked for a specified time, causing service disruptions. This disruption is triggered by a "sleep()" call in the "dcesrv_echo_TestSleep()" function under specific conditions. Authenticated users or attackers can exploit this vulnerability to make calls to the "rpcecho" server, requesting it to block for a specified duration, effectively disrupting most services and leading to a complete denial of service on the AD DC. The DoS affects all other services as "rpcecho" runs in the main RPC task.
- https://access.redhat.com/errata/RHSA-2023:6209
- https://access.redhat.com/errata/RHSA-2023:6744
- https://access.redhat.com/errata/RHSA-2023:7371
- https://access.redhat.com/errata/RHSA-2023:7408
- https://access.redhat.com/errata/RHSA-2023:7464
- https://access.redhat.com/errata/RHSA-2023:7467
- https://access.redhat.com/security/cve/CVE-2023-42669
- https://bugzilla.redhat.com/show_bug.cgi?id=2241884
- https://bugzilla.samba.org/show_bug.cgi?id=15474
- https://www.samba.org/samba/security/CVE-2023-42669.html
- https://access.redhat.com/errata/RHSA-2023:6209
- https://access.redhat.com/errata/RHSA-2023:6744
- https://access.redhat.com/errata/RHSA-2023:7371
- https://access.redhat.com/errata/RHSA-2023:7408
- https://access.redhat.com/errata/RHSA-2023:7464
- https://access.redhat.com/errata/RHSA-2023:7467
- https://access.redhat.com/security/cve/CVE-2023-42669
- https://bugzilla.redhat.com/show_bug.cgi?id=2241884
- https://bugzilla.samba.org/show_bug.cgi?id=15474
- https://security.netapp.com/advisory/ntap-20231124-0002/
- https://www.samba.org/samba/security/CVE-2023-42669.html
Modified: 2024-11-21
CVE-2023-42670
A flaw was found in Samba. It is susceptible to a vulnerability where multiple incompatible RPC listeners can be initiated, causing disruptions in the AD DC service. When Samba's RPC server experiences a high load or unresponsiveness, servers intended for non-AD DC purposes (for example, NT4-emulation "classic DCs") can erroneously start and compete for the same unix domain sockets. This issue leads to partial query responses from the AD DC, causing issues such as "The procedure number is out of range" when using tools like Active Directory Users. This flaw allows an attacker to disrupt AD DC services.
- https://access.redhat.com/security/cve/CVE-2023-42670
- https://bugzilla.redhat.com/show_bug.cgi?id=2241885
- https://bugzilla.samba.org/show_bug.cgi?id=15473
- https://www.samba.org/samba/security/CVE-2023-42670.html
- https://access.redhat.com/security/cve/CVE-2023-42670
- https://bugzilla.redhat.com/show_bug.cgi?id=2241885
- https://bugzilla.samba.org/show_bug.cgi?id=15473
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZUMVALLFFDFC53JZMUWA6HPD7HUGAP5I/
- https://security.netapp.com/advisory/ntap-20231124-0002/
- https://www.samba.org/samba/security/CVE-2023-42670.html
Closed bugs
Missing dependency for include
Closed vulnerabilities
Modified: 2024-09-02
BDU:2023-09013
Уязвимость пакета filepath языка программирования Go, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-08-06
BDU:2024-00175
Уязвимость пакета net/http языка программирования Go, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-08-06
BDU:2024-00176
Уязвимость компонента cmd-go языка программирования Go, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-11-21
CVE-2023-39326
A malicious HTTP sender can use chunk extensions to cause a receiver reading from a request or response body to read many more bytes from the network than are in the body. A malicious HTTP client can further exploit this to cause a server to automatically read a large amount of data (up to about 1GiB) when a handler fails to read the entire body of a request. Chunk extensions are a little-used HTTP feature which permit including additional metadata in a request or response body sent using the chunked encoding. The net/http chunked encoding reader discards this metadata. A sender can exploit this by inserting a large metadata segment with each byte transferred. The chunk reader now produces an error if the ratio of real body to encoded bytes grows too small.
- https://go.dev/cl/547335
- https://go.dev/issue/64433
- https://groups.google.com/g/golang-dev/c/6ypN5EjibjM/m/KmLVYH_uAgAJ
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UIU6HOGV6RRIKWM57LOXQA75BGZSIH6G/
- https://pkg.go.dev/vuln/GO-2023-2382
- https://go.dev/cl/547335
- https://go.dev/issue/64433
- https://groups.google.com/g/golang-dev/c/6ypN5EjibjM/m/KmLVYH_uAgAJ
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UIU6HOGV6RRIKWM57LOXQA75BGZSIH6G/
- https://pkg.go.dev/vuln/GO-2023-2382
Modified: 2024-11-21
CVE-2023-45283
The filepath package does not recognize paths with a \??\ prefix as special. On Windows, a path beginning with \??\ is a Root Local Device path equivalent to a path beginning with \\?\. Paths with a \??\ prefix may be used to access arbitrary locations on the system. For example, the path \??\c:\x is equivalent to the more common path c:\x. Before fix, Clean could convert a rooted path such as \a\..\??\b into the root local device path \??\b. Clean will now convert this to .\??\b. Similarly, Join(\, ??, b) could convert a seemingly innocent sequence of path elements into the root local device path \??\b. Join will now convert this to \.\??\b. In addition, with fix, IsAbs now correctly reports paths beginning with \??\ as absolute, and VolumeName correctly reports the \??\ prefix as a volume name. UPDATE: Go 1.20.11 and Go 1.21.4 inadvertently changed the definition of the volume name in Windows paths starting with \?, resulting in filepath.Clean(\?\c:) returning \?\c: rather than \?\c:\ (among other effects). The previous behavior has been restored.
- http://www.openwall.com/lists/oss-security/2023/12/05/2
- https://go.dev/cl/540277
- https://go.dev/cl/541175
- https://go.dev/issue/63713
- https://go.dev/issue/64028
- https://groups.google.com/g/golang-announce/c/4tU8LZfBFkY
- https://groups.google.com/g/golang-dev/c/6ypN5EjibjM/m/KmLVYH_uAgAJ
- https://pkg.go.dev/vuln/GO-2023-2185
- https://security.netapp.com/advisory/ntap-20231214-0008/
- http://www.openwall.com/lists/oss-security/2023/12/05/2
- https://go.dev/cl/540277
- https://go.dev/cl/541175
- https://go.dev/issue/63713
- https://go.dev/issue/64028
- https://groups.google.com/g/golang-announce/c/4tU8LZfBFkY
- https://groups.google.com/g/golang-dev/c/6ypN5EjibjM/m/KmLVYH_uAgAJ
- https://pkg.go.dev/vuln/GO-2023-2185
- https://security.netapp.com/advisory/ntap-20231214-0008/
Modified: 2024-11-21
CVE-2023-45285
Using go get to fetch a module with the ".git" suffix may unexpectedly fallback to the insecure "git://" protocol if the module is unavailable via the secure "https://" and "git+ssh://" protocols, even if GOINSECURE is not set for said module. This only affects users who are not using the module proxy and are fetching modules directly (i.e. GOPROXY=off).
- https://go.dev/cl/540257
- https://go.dev/issue/63845
- https://groups.google.com/g/golang-dev/c/6ypN5EjibjM/m/KmLVYH_uAgAJ
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UIU6HOGV6RRIKWM57LOXQA75BGZSIH6G/
- https://pkg.go.dev/vuln/GO-2023-2383
- https://go.dev/cl/540257
- https://go.dev/issue/63845
- https://groups.google.com/g/golang-dev/c/6ypN5EjibjM/m/KmLVYH_uAgAJ
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UIU6HOGV6RRIKWM57LOXQA75BGZSIH6G/
- https://pkg.go.dev/vuln/GO-2023-2383
Package exfatprogs updated to version 1.2.2-alt1 for branch p10 in task 335282.
Closed vulnerabilities
Modified: 2025-09-22
BDU:2024-03156
Уязвимость функции read_file_dentry_set утилиты пользовательского пространства exfatprogs, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2024-11-21
CVE-2023-45897
exfatprogs before 1.2.2 allows out-of-bounds memory access, such as in read_file_dentry_set.
- https://dfir.ru/2023/11/01/cve-2023-45897-a-vulnerability-in-the-linux-exfat-userspace-tools/
- https://github.com/exfatprogs/exfatprogs/commit/22d0e43e8d24119cbfc6efafabb0dec6517a86c4
- https://github.com/exfatprogs/exfatprogs/commit/4abc55e976573991e6a1117bb2b3711e59da07ae
- https://github.com/exfatprogs/exfatprogs/commit/ec78688e5fb5a70e13df82b4c0da1e6228d3ccdf
- https://github.com/exfatprogs/exfatprogs/releases/tag/1.2.2
- https://dfir.ru/2023/11/01/cve-2023-45897-a-vulnerability-in-the-linux-exfat-userspace-tools/
- https://github.com/exfatprogs/exfatprogs/commit/22d0e43e8d24119cbfc6efafabb0dec6517a86c4
- https://github.com/exfatprogs/exfatprogs/commit/4abc55e976573991e6a1117bb2b3711e59da07ae
- https://github.com/exfatprogs/exfatprogs/commit/ec78688e5fb5a70e13df82b4c0da1e6228d3ccdf
- https://github.com/exfatprogs/exfatprogs/releases/tag/1.2.2
- https://lists.debian.org/debian-lts-announce/2024/09/msg00003.html
