ALT-BU-2024-7519-2
Branch sisyphus update bulletin.
Package kernel-modules-virtualbox-addition-un-def updated to version 7.0.18-alt1.394782.1 for branch sisyphus in task 347433.
Closed vulnerabilities
Modified: 2024-11-14
BDU:2024-03172
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03229
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии или выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03425
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код и повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03472
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03479
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03501
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03538
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-05402
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-05407
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-11-14
BDU:2024-05430
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-14
BDU:2024-05431
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-11-14
BDU:2024-05433
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-18
BDU:2024-05437
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-03-13
CVE-2024-21103
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21106
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).
Modified: 2025-05-08
CVE-2024-21107
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 6.7 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21108
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 3.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
Modified: 2024-12-05
CVE-2024-21109
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).
Modified: 2025-05-08
CVE-2024-21110
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H).
Modified: 2025-05-09
CVE-2024-21111
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-28
CVE-2024-21112
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-18
CVE-2024-21113
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-05-08
CVE-2024-21114
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-25
CVE-2024-21115
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-06-09
CVE-2024-21116
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-27
CVE-2024-21121
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N).
Package virtualbox updated to version 7.0.18-alt1 for branch sisyphus in task 347433.
Closed vulnerabilities
Modified: 2024-11-14
BDU:2024-03172
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03229
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии или выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03425
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код и повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03472
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03479
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03501
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03538
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-05402
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-05407
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-11-14
BDU:2024-05430
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-14
BDU:2024-05431
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-11-14
BDU:2024-05433
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-18
BDU:2024-05437
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-03-13
CVE-2024-21103
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21106
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).
Modified: 2025-05-08
CVE-2024-21107
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 6.7 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21108
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 3.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
Modified: 2024-12-05
CVE-2024-21109
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).
Modified: 2025-05-08
CVE-2024-21110
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H).
Modified: 2025-05-09
CVE-2024-21111
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-28
CVE-2024-21112
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-18
CVE-2024-21113
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-05-08
CVE-2024-21114
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-25
CVE-2024-21115
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-06-09
CVE-2024-21116
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-27
CVE-2024-21121
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N).
Package kernel-image-pine updated to version 6.6.30-alt1 for branch sisyphus in task 347545.
Closed vulnerabilities
Modified: 2026-01-20
BDU:2024-03625
Уязвимость функции nft_pipapo_remove() в модуле net/netfilter/nft_set_pipapo.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03634
Уязвимость функции __i915_vma_active() в модуле drivers/gpu/drm/i915/i915_vma.c драйвера графических адаптеров Intel 8xx/9xx/G3x/G4x/HD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03640
Уязвимость функции __handle_ksmbd_work() реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03641
Уязвимость функций ncm_set_alt() и ncm_disable() в модуле drivers/usb/gadget/function/f_ncm.c драйвера USB gadget ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-03932
Уязвимость функции ovs_ct_limit_exit() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-03933
Уязвимость функции gtp_dellink() реализации протокола туннелирования GPRS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-23
BDU:2024-04218
Уязвимость функции smb2_reconnect_server() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-04227
Уязвимость функции mlxsw_sp_acl_tcam_ventry_activity_get() драйвера Mellanox Technologies Switch ASICs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-04228
Уязвимость функции mlxsw_sp_acl_tcam_vregion_rehash() драйвера Mellanox Technologies Switch ASICs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-04582
Уязвимость функции br_nf_local_in() компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-06
BDU:2024-04584
Уязвимость функции dup_mmap() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04587
Уязвимость функции nft_expr_type_get() компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-06488
Уязвимость функции ip_route_use_hint() в компоненте ipv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06497
Уязвимость функции i2c_hid_xfer() в компоненте i2c-hid ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-06498
Уязвимость компонента xilinx_dpdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06499
Уязвимость компонента smbus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-06502
Уязвимость функции __nft_obj_type_get() в компоненте nf_tables ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-08-19
BDU:2024-06503
Уязвимость компонента tun ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-07640
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код
Modified: 2026-01-20
BDU:2024-07641
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09321
Уязвимость компонента sysfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2024-09322
Уязвимость компонента speakup ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09323
Уязвимость компонента dwc2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09326
Уязвимость компонентов serial/pmac_zilog ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09328
Уязвимость компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09329
Уязвимость компонента vmk80xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09330
Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09332
Уязвимость компонента drm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09339
Уязвимость компонентов s390/cio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09340
Уязвимость компонента binder ядра операционной системы Linux, позволяющая нарушителю выполнять произвольный код
Modified: 2025-05-06
BDU:2024-09343
Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09352
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-04-29
BDU:2024-09353
Уязвимость компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09355
Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09370
Уязвимость компонентов mm/memory-failure ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-09859
Уязвимость компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09866
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09997
Уязвимость компонентов x86/mmu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09998
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10001
Уязвимость компонента hibernate ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10002
Уязвимость компонента init ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-10004
Уязвимость компонента nouveau ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10037
Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10044
Уязвимость компонента bcmasp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10046
Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10047
Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10066
Уязвимость компонента icmp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10067
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-08-19
BDU:2024-10071
Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10072
Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10511
Уязвимость компонентов irqchip/gic-v3-its ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10696
Уязвимость компонента sdhci-msm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02920
Уязвимость функции mtk_clk_simple_probe() модуля drivers/clk/mediatek/clk-mtk.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-02928
Уязвимость функции mlx5e_arfs_enable() модуля drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03062
Уязвимость функции cifs_pick_channel() модуля fs/smb/client/transport.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03063
Уязвимость функции ice_reset_vf() модуля drivers/net/ethernet/intel/ice/ice_vf_lib.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03064
Уязвимость функции perf_event_cpu_offline() модуля drivers/dma/idxd/perfmon.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03065
Уязвимость функции cifs_sync_mid_result() модуля fs/smb/client/transport.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03066
Уязвимость функции comphy_gbe_phy_init() модуля drivers/phy/marvell/phy-mvebu-a3700-comphy.c драйвера PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-03067
Уязвимость функции mlxsw_sp_acl_tcam_vregion_rehash_work() модуля drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03068
Уязвимость функции tusb1210_remove_charger_detect() модуля drivers/phy/ti/phy-tusb1210.c драйвера PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03069
Уязвимость функции avg_vruntime() модуля kernel/sched/fair.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03070
Уязвимость функции main() модуля kernel/bounds.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-03071
Уязвимость функции virtnet_get_rxfh() модуля drivers/net/virtio_net.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03072
Уязвимость функции get_trans_granule() модуля arch/arm64/include/asm/tlbflush.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03446
Уязвимость компонента ACPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03614
Уязвимость функции path_init() модуля drivers/interconnect/core.c - драйвера поддержки межсоединений ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03905
Уязвимость компонента spectrum_acl_tcam.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03906
Уязвимость компонента nft_chain_filter.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2025-03913
Уязвимость компонента i40e_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03914
Уязвимость компонента pgtable.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-06992
Уязвимость функции xbc_init() модуля include/linux/bootconfig.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-07414
Уязвимость функции cifs_get_tcon_super() модуля fs/smb/client/cifsproto.h поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-08076
Уязвимость компонента af_ax25.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08077
Уязвимость компонента hugetlb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08078
Уязвимость компонентов Kconfig, cpu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08079
Уязвимость компонентов page-flags.h, mmflags.h, vmcore_info.c, hugetlb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08080
Уязвимость компонентов cdev.c, debugfs.c, device.c, idxd.h, init.c, irq.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-08081
Уязвимость компонентов page.h, init.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-11885
Уязвимость компонента fs/squashfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2025-12-23
CVE-2024-26922
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate the parameters of bo mapping operations more clearly Verify the parameters of amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.
- https://git.kernel.org/stable/c/1fd7db5c16028dc07b2ceec190f2e895dddb532d
- https://git.kernel.org/stable/c/212e3baccdb1939606420d88f7f52d346b49a284
- https://git.kernel.org/stable/c/6fef2d4c00b5b8561ad68dd2b68173f5c6af1e75
- https://git.kernel.org/stable/c/8b12fc7b032633539acdf7864888b0ebd49e90f2
- https://git.kernel.org/stable/c/b1f04b9b1c5317f562a455384c5f7473e46bdbaa
- https://git.kernel.org/stable/c/d4da6b084f1c5625937d49bb6722c5b4aef11b8d
- https://git.kernel.org/stable/c/ef13eeca7c79136bc38e21eb67322c1cbd5c40ee
- https://git.kernel.org/stable/c/f68039375d4d6d67303674c0ab2d06b7295c0ec9
- https://git.kernel.org/stable/c/1fd7db5c16028dc07b2ceec190f2e895dddb532d
- https://git.kernel.org/stable/c/212e3baccdb1939606420d88f7f52d346b49a284
- https://git.kernel.org/stable/c/6fef2d4c00b5b8561ad68dd2b68173f5c6af1e75
- https://git.kernel.org/stable/c/8b12fc7b032633539acdf7864888b0ebd49e90f2
- https://git.kernel.org/stable/c/b1f04b9b1c5317f562a455384c5f7473e46bdbaa
- https://git.kernel.org/stable/c/d4da6b084f1c5625937d49bb6722c5b4aef11b8d
- https://git.kernel.org/stable/c/ef13eeca7c79136bc38e21eb67322c1cbd5c40ee
- https://git.kernel.org/stable/c/f68039375d4d6d67303674c0ab2d06b7295c0ec9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26924
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano)
- https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487
- https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc
- https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644
- https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46
- https://git.kernel.org/stable/c/e3b887a9c11caf8357a821260e095f2a694a34f2
- https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a
- https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487
- https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc
- https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644
- https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46
- https://git.kernel.org/stable/c/e3b887a9c11caf8357a821260e095f2a694a34f2
- https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-26926
In the Linux kernel, the following vulnerability has been resolved: binder: check offset alignment in binder_get_object() Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying txn") introduced changes to how binder objects are copied. In doing so, it unintentionally removed an offset alignment check done through calls to binder_alloc_copy_from_buffer() -> check_buffer(). These calls were replaced in binder_get_object() with copy_from_user(), so now an explicit offset alignment check is needed here. This avoids later complications when unwinding the objects gets harder. It is worth noting this check existed prior to commit 7a67a39320df ("binder: add function to copy binder object from buffer"), likely removed due to redundancy at the time.
- https://git.kernel.org/stable/c/1d7f1049035b2060342f11eff957cf567d810bdc
- https://git.kernel.org/stable/c/48a1f83ca9c68518b1a783c62e6a8223144fa9fc
- https://git.kernel.org/stable/c/68a28f551e4690db2b27b3db716c7395f6fada12
- https://git.kernel.org/stable/c/a2fd6dbc98be1105a1d8e9e31575da8873ef115c
- https://git.kernel.org/stable/c/a6d2a8b211c874971ee4cf3ddd167408177f6e76
- https://git.kernel.org/stable/c/aaef73821a3b0194a01bd23ca77774f704a04d40
- https://git.kernel.org/stable/c/f01d6619045704d78613b14e2e0420bfdb7f1c15
- https://git.kernel.org/stable/c/1d7f1049035b2060342f11eff957cf567d810bdc
- https://git.kernel.org/stable/c/48a1f83ca9c68518b1a783c62e6a8223144fa9fc
- https://git.kernel.org/stable/c/68a28f551e4690db2b27b3db716c7395f6fada12
- https://git.kernel.org/stable/c/a2fd6dbc98be1105a1d8e9e31575da8873ef115c
- https://git.kernel.org/stable/c/a6d2a8b211c874971ee4cf3ddd167408177f6e76
- https://git.kernel.org/stable/c/aaef73821a3b0194a01bd23ca77774f704a04d40
- https://git.kernel.org/stable/c/f01d6619045704d78613b14e2e0420bfdb7f1c15
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-18
CVE-2024-26936
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate request buffer size in smb2_allocate_rsp_buf() The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.
- https://git.kernel.org/stable/c/17cf0c2794bdb6f39671265aa18aea5c22ee8c4a
- https://git.kernel.org/stable/c/21ff9d7d223c5c19cb4334009e4c0c83a2f4d674
- https://git.kernel.org/stable/c/2c27a64a2bc47d9bfc7c3cf8be14be53b1ee7cb6
- https://git.kernel.org/stable/c/5c20b242d4fed73a93591e48bfd9772e2322fb11
- https://git.kernel.org/stable/c/8f3d0bf1d0c62b539d54c5b9108a845cff619b99
- https://git.kernel.org/stable/c/17cf0c2794bdb6f39671265aa18aea5c22ee8c4a
- https://git.kernel.org/stable/c/21ff9d7d223c5c19cb4334009e4c0c83a2f4d674
- https://git.kernel.org/stable/c/2c27a64a2bc47d9bfc7c3cf8be14be53b1ee7cb6
- https://git.kernel.org/stable/c/5c20b242d4fed73a93591e48bfd9772e2322fb11
- https://git.kernel.org/stable/c/8f3d0bf1d0c62b539d54c5b9108a845cff619b99
Modified: 2025-04-08
CVE-2024-26939
In the Linux kernel, the following vulnerability has been resolved: drm/i915/vma: Fix UAF on destroy against retire race Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915] [161.360592] RIP: 0010:debug_print_object+0x80/0xb0 ... [161.361347] debug_object_free+0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] release_references+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] [161.363129] __gt_park+0x121/0x230 [i915] [161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915] That has been tracked down to be happening when another thread is deactivating the VMA inside __active_retire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool. We could prevent from that race by serializing i915_active_fini() with __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from being used, e.g. from __i915_vma_retire() called at the end of __active_retire(), after that VMA has been already freed by a concurrent i915_vma_destroy() on return from the i915_active_fini(). Then, we should rather fix the issue at the VMA level, not in i915_active. Since __i915_vma_parked() is called from __gt_park() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for __active_retire() to complete before that wakeref is released and the GT parked. I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915_active_fini() from a dropped i915_vma_release(), called on last put of the removed VMA kref, to i915_vma_parked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915_active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation"). A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intel_context for a GT associated with its VM, and indirectly on that intel_context's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation. Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since __i915_vma_retire() may be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed. v7: Add inline comments with justifications for: - using untracked variants of intel_gt_pm_get/put() (Nirmoy), - using async variant of _put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since __i915_vma_active/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915_vma is not safe, and there is no other good place for that. Use untracked variants of intel_gt_pm_get/put_async(). v5: Replace "tile" with "GT" across commit description (Rodrigo), - ---truncated---
- https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e
- https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f
- https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5
- https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190
- https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e
- https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f
- https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5
- https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190
Modified: 2025-11-04
CVE-2024-26980
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in smb2_allocate_rsp_buf(). This patch allocate response buffer after decrypting transform request. smb3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf().
- https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085
- https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1
- https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248
- https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20
- https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325
- https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085
- https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1
- https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248
- https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20
- https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26981
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix OOB in nilfs_set_de_type The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob } However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.
- https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243
- https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9
- https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1
- https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611
- https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f416975f
- https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8
- https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0
- https://git.kernel.org/stable/c/c4a7dc9523b59b3e73fd522c73e95e072f876b16
- https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243
- https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9
- https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1
- https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611
- https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f416975f
- https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8
- https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0
- https://git.kernel.org/stable/c/c4a7dc9523b59b3e73fd522c73e95e072f876b16
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26982
In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix]
- https://git.kernel.org/stable/c/32c114a58236fe67141634774559f21f1dc96fd7
- https://git.kernel.org/stable/c/4a1b6f89825e267e156ccaeba3d235edcac77f94
- https://git.kernel.org/stable/c/5b99dea79650b50909c50aba24fbae00f203f013
- https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5
- https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395
- https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e
- https://git.kernel.org/stable/c/cf46f88b92cfc0e32bd8a21ba1273cff13b8745f
- https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5
- https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395
- https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26983
In the Linux kernel, the following vulnerability has been resolved:
bootconfig: use memblock_free_late to free xbc memory to buddy
On the time to free xbc memory in xbc_exit(), memblock may has handed
over memory to buddy allocator. So it doesn't make sense to free memory
back to memblock. memblock_free() called by xbc_exit() even causes UAF bugs
on architectures with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86.
Following KASAN logs shows this case.
This patch fixes the xbc memory free problem by calling memblock_free()
in early xbc init error rewind path and calling memblock_free_late() in
xbc exit path to free memory to buddy allocator.
[ 9.410890] ==================================================================
[ 9.418962] BUG: KASAN: use-after-free in memblock_isolate_range+0x12d/0x260
[ 9.426850] Read of size 8 at addr ffff88845dd30000 by task swapper/0/1
[ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Tainted: G U 6.9.0-rc3-00208-g586b5dfb51b9 #5
[ 9.446403] Hardware name: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023
[ 9.460789] Call Trace:
[ 9.463518]
- https://git.kernel.org/stable/c/1e7feb31a18c197d63a5e606025ed63c762f8918
- https://git.kernel.org/stable/c/5a7dfb8fcd3f29fc93161100179b27f24f3d5f35
- https://git.kernel.org/stable/c/89f9a1e876b5a7ad884918c03a46831af202c8a0
- https://git.kernel.org/stable/c/e46d3be714ad9652480c6db129ab8125e2d20ab7
- https://git.kernel.org/stable/c/1e7feb31a18c197d63a5e606025ed63c762f8918
- https://git.kernel.org/stable/c/5a7dfb8fcd3f29fc93161100179b27f24f3d5f35
- https://git.kernel.org/stable/c/89f9a1e876b5a7ad884918c03a46831af202c8a0
- https://git.kernel.org/stable/c/e46d3be714ad9652480c6db129ab8125e2d20ab7
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26984
In the Linux kernel, the following vulnerability has been resolved: nouveau: fix instmem race condition around ptr stores Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read. v2: use paired smp_rmb/smp_wmb.
- https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716
- https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7
- https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52
- https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572
- https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525
- https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039
- https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9
- https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce
- https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716
- https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7
- https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52
- https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572
- https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525
- https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039
- https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9
- https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26986
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix memory leak in create_process failure Fix memory leak due to a leaked mmget reference on an error handling code path that is triggered when attempting to create KFD processes while a GPU reset is in progress.
- https://git.kernel.org/stable/c/0dcd876411644da98a6b4d5a18d32ca94c15bdb5
- https://git.kernel.org/stable/c/18921b205012568b45760753ad3146ddb9e2d4e2
- https://git.kernel.org/stable/c/aa02d43367a9adf8c85fb382fea4171fb266c8d0
- https://git.kernel.org/stable/c/0dcd876411644da98a6b4d5a18d32ca94c15bdb5
- https://git.kernel.org/stable/c/18921b205012568b45760753ad3146ddb9e2d4e2
- https://git.kernel.org/stable/c/aa02d43367a9adf8c85fb382fea4171fb266c8d0
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26987
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
When I did hard offline test with hugetlb pages, below deadlock occurs:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-11409-gf6cef5f8c37f #1 Not tainted
------------------------------------------------------
bash/46904 is trying to acquire lock:
ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock:
ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}:
__mutex_lock+0x6c/0x770
page_alloc_cpu_online+0x3c/0x70
cpuhp_invoke_callback+0x397/0x5f0
__cpuhp_invoke_callback_range+0x71/0xe0
_cpu_up+0xeb/0x210
cpu_up+0x91/0xe0
cpuhp_bringup_mask+0x49/0xb0
bringup_nonboot_cpus+0xb7/0xe0
smp_init+0x25/0xa0
kernel_init_freeable+0x15f/0x3e0
kernel_init+0x15/0x1b0
ret_from_fork+0x2f/0x50
ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x1298/0x1cd0
lock_acquire+0xc0/0x2b0
cpus_read_lock+0x2a/0xc0
static_key_slow_dec+0x16/0x60
__hugetlb_vmemmap_restore_folio+0x1b9/0x200
dissolve_free_huge_page+0x211/0x260
__page_handle_poison+0x45/0xc0
memory_failure+0x65e/0xc70
hard_offline_page_store+0x55/0xa0
kernfs_fop_write_iter+0x12c/0x1d0
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xca/0x1e0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcp_batch_high_lock);
lock(cpu_hotplug_lock);
lock(pcp_batch_high_lock);
rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904:
#0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0
#1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0
#2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0
#3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70
#4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace:
CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1983184c22dd84a4d95a71e5c6775c2638557dc7
- https://git.kernel.org/stable/c/49955b24002dc16a0ae2e83a57a2a6c863a1845c
- https://git.kernel.org/stable/c/5ef7ba2799a3b5ed292b8f6407376e2c25ef002e
- https://git.kernel.org/stable/c/882e1180c83f5b75bae03d0ccc31ccedfe5159de
- https://git.kernel.org/stable/c/1983184c22dd84a4d95a71e5c6775c2638557dc7
- https://git.kernel.org/stable/c/49955b24002dc16a0ae2e83a57a2a6c863a1845c
- https://git.kernel.org/stable/c/5ef7ba2799a3b5ed292b8f6407376e2c25ef002e
- https://git.kernel.org/stable/c/882e1180c83f5b75bae03d0ccc31ccedfe5159de
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-26988
In the Linux kernel, the following vulnerability has been resolved: init/main.c: Fix potential static_command_line memory overflow We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for static_command_line, but the strings copied into static_command_line are extra_command_line and command_line, rather than extra_command_line and boot_command_line. When strlen(command_line) > strlen(boot_command_line), static_command_line will overflow. This patch just recovers strlen(command_line) which was miss-consolidated with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add checks for the return value of memblock_alloc*()")
- https://git.kernel.org/stable/c/0dc727a4e05400205358a22c3d01ccad2c8e1fe4
- https://git.kernel.org/stable/c/2ef607ea103616aec0289f1b65d103d499fa903a
- https://git.kernel.org/stable/c/46dad3c1e57897ab9228332f03e1c14798d2d3b9
- https://git.kernel.org/stable/c/76c2f4d426a5358fced5d5990744d46f10a4ccea
- https://git.kernel.org/stable/c/81cf85ae4f2dd5fa3e43021782aa72c4c85558e8
- https://git.kernel.org/stable/c/936a02b5a9630c5beb0353c3085cc49d86c57034
- https://git.kernel.org/stable/c/0dc727a4e05400205358a22c3d01ccad2c8e1fe4
- https://git.kernel.org/stable/c/2ef607ea103616aec0289f1b65d103d499fa903a
- https://git.kernel.org/stable/c/46dad3c1e57897ab9228332f03e1c14798d2d3b9
- https://git.kernel.org/stable/c/76c2f4d426a5358fced5d5990744d46f10a4ccea
- https://git.kernel.org/stable/c/81cf85ae4f2dd5fa3e43021782aa72c4c85558e8
- https://git.kernel.org/stable/c/936a02b5a9630c5beb0353c3085cc49d86c57034
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26989
In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Fix level3 translation fault in swsusp_save() On arm64 machines, swsusp_save() faults if it attempts to access MEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFI when booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n: Unable to handle kernel paging request at virtual address ffffff8000000000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000 [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76 Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0 Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021 pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : swsusp_save+0x280/0x538 lr : swsusp_save+0x280/0x538 sp : ffffffa034a3fa40 x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000 x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000 x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2 x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000 x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666 x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0 x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001 x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e Call trace: swsusp_save+0x280/0x538 swsusp_arch_suspend+0x148/0x190 hibernation_snapshot+0x240/0x39c hibernate+0xc4/0x378 state_store+0xf0/0x10c kobj_attr_store+0x14/0x24 The reason is swsusp_save() -> copy_data_pages() -> page_is_saveable() -> kernel_page_present() assuming that a page is always present when can_set_direct_map() is false (all of rodata_full, debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false), irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regions should not be saved during hibernation. This problem was introduced by changes to the pfn_valid() logic in commit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify pfn_valid()"). Similar to other architectures, drop the !can_set_direct_map() check in kernel_page_present() so that page_is_savable() skips such pages. [catalin.marinas@arm.com: rework commit message]
- https://git.kernel.org/stable/c/022b19ebc31cce369c407617041a3db810db23b3
- https://git.kernel.org/stable/c/31f815cb436082e72d34ed2e8a182140a73ebdf4
- https://git.kernel.org/stable/c/50449ca66cc5a8cbc64749cf4b9f3d3fc5f4b457
- https://git.kernel.org/stable/c/813f5213f2c612dc800054859aaa396ec8ad7069
- https://git.kernel.org/stable/c/f7e71a7cf399f53ff9fc314ca3836dc913b05bd6
- https://git.kernel.org/stable/c/022b19ebc31cce369c407617041a3db810db23b3
- https://git.kernel.org/stable/c/31f815cb436082e72d34ed2e8a182140a73ebdf4
- https://git.kernel.org/stable/c/50449ca66cc5a8cbc64749cf4b9f3d3fc5f4b457
- https://git.kernel.org/stable/c/813f5213f2c612dc800054859aaa396ec8ad7069
- https://git.kernel.org/stable/c/f7e71a7cf399f53ff9fc314ca3836dc913b05bd6
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26990
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status Check kvm_mmu_page_ad_need_write_protect() when deciding whether to write-protect or clear D-bits on TDP MMU SPTEs, so that the TDP MMU accounts for any role-specific reasons for disabling D-bit dirty logging. Specifically, TDP MMU SPTEs must be write-protected when the TDP MMU is being used to run an L2 (i.e. L1 has disabled EPT) and PML is enabled. KVM always disables PML when running L2, even when L1 and L2 GPAs are in the some domain, so failing to write-protect TDP MMU SPTEs will cause writes made by L2 to not be reflected in the dirty log. [sean: massage shortlog and changelog, tweak ternary op formatting]
- https://git.kernel.org/stable/c/2673dfb591a359c75080dd5af3da484b89320d22
- https://git.kernel.org/stable/c/cdf811a937471af2d1facdf8ae80e5e68096f1ed
- https://git.kernel.org/stable/c/e20bff0f1b2de9cfe303dd35ff46470104a87404
- https://git.kernel.org/stable/c/2673dfb591a359c75080dd5af3da484b89320d22
- https://git.kernel.org/stable/c/cdf811a937471af2d1facdf8ae80e5e68096f1ed
- https://git.kernel.org/stable/c/e20bff0f1b2de9cfe303dd35ff46470104a87404
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26992
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/pmu: Disable support for adaptive PEBS Drop support for virtualizing adaptive PEBS, as KVM's implementation is architecturally broken without an obvious/easy path forward, and because exposing adaptive PEBS can leak host LBRs to the guest, i.e. can leak host kernel addresses to the guest. Bug #1 is that KVM doesn't account for the upper 32 bits of IA32_FIXED_CTR_CTRL when (re)programming fixed counters, e.g fixed_ctrl_field() drops the upper bits, reprogram_fixed_counters() stores local variables as u8s and truncates the upper bits too, etc. Bug #2 is that, because KVM _always_ sets precise_ip to a non-zero value for PEBS events, perf will _always_ generate an adaptive record, even if the guest requested a basic record. Note, KVM will also enable adaptive PEBS in individual *counter*, even if adaptive PEBS isn't exposed to the guest, but this is benign as MSR_PEBS_DATA_CFG is guaranteed to be zero, i.e. the guest will only ever see Basic records. Bug #3 is in perf. intel_pmu_disable_fixed() doesn't clear the upper bits either, i.e. leaves ICL_FIXED_0_ADAPTIVE set, and intel_pmu_enable_fixed() effectively doesn't clear ICL_FIXED_0_ADAPTIVE either. I.e. perf _always_ enables ADAPTIVE counters, regardless of what KVM requests. Bug #4 is that adaptive PEBS *might* effectively bypass event filters set by the host, as "Updated Memory Access Info Group" records information that might be disallowed by userspace via KVM_SET_PMU_EVENT_FILTER. Bug #5 is that KVM doesn't ensure LBR MSRs hold guest values (or at least zeros) when entering a vCPU with adaptive PEBS, which allows the guest to read host LBRs, i.e. host RIPs/addresses, by enabling "LBR Entries" records. Disable adaptive PEBS support as an immediate fix due to the severity of the LBR leak in particular, and because fixing all of the bugs will be non-trivial, e.g. not suitable for backporting to stable kernels. Note! This will break live migration, but trying to make KVM play nice with live migration would be quite complicated, wouldn't be guaranteed to work (i.e. KVM might still kill/confuse the guest), and it's not clear that there are any publicly available VMMs that support adaptive PEBS, let alone live migrate VMs that support adaptive PEBS, e.g. QEMU doesn't support PEBS in any capacity.
- https://git.kernel.org/stable/c/037e48ceccf163899374b601afb6ae8d0bf1d2ac
- https://git.kernel.org/stable/c/0fb74c00d140a66128afc0003785dcc57e69d312
- https://git.kernel.org/stable/c/7a7650b3ac23e5fc8c990f00e94f787dc84e3175
- https://git.kernel.org/stable/c/9e985cbf2942a1bb8fcef9adc2a17d90fd7ca8ee
- https://git.kernel.org/stable/c/037e48ceccf163899374b601afb6ae8d0bf1d2ac
- https://git.kernel.org/stable/c/0fb74c00d140a66128afc0003785dcc57e69d312
- https://git.kernel.org/stable/c/7a7650b3ac23e5fc8c990f00e94f787dc84e3175
- https://git.kernel.org/stable/c/9e985cbf2942a1bb8fcef9adc2a17d90fd7ca8ee
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26993
In the Linux kernel, the following vulnerability has been resolved: fs: sysfs: Fix reference leak in sysfs_break_active_protection() The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL.
- https://git.kernel.org/stable/c/43f00210cb257bcb0387e8caeb4b46375d67f30c
- https://git.kernel.org/stable/c/57baab0f376bec8f54b0fe6beb8f77a57c228063
- https://git.kernel.org/stable/c/5d43e072285e81b0b63cee7189b3357c7768a43b
- https://git.kernel.org/stable/c/84bd4c2ae9c3d0a7d3a5c032ea7efff17af17e17
- https://git.kernel.org/stable/c/a4c99b57d43bab45225ba92d574a8683f9edc8e4
- https://git.kernel.org/stable/c/a90bca2228c0646fc29a72689d308e5fe03e6d78
- https://git.kernel.org/stable/c/ac107356aabc362aaeb77463e814fc067a5d3957
- https://git.kernel.org/stable/c/f28bba37fe244889b81bb5c508d3f6e5c6e342c5
- https://git.kernel.org/stable/c/43f00210cb257bcb0387e8caeb4b46375d67f30c
- https://git.kernel.org/stable/c/57baab0f376bec8f54b0fe6beb8f77a57c228063
- https://git.kernel.org/stable/c/5d43e072285e81b0b63cee7189b3357c7768a43b
- https://git.kernel.org/stable/c/84bd4c2ae9c3d0a7d3a5c032ea7efff17af17e17
- https://git.kernel.org/stable/c/a4c99b57d43bab45225ba92d574a8683f9edc8e4
- https://git.kernel.org/stable/c/a90bca2228c0646fc29a72689d308e5fe03e6d78
- https://git.kernel.org/stable/c/ac107356aabc362aaeb77463e814fc067a5d3957
- https://git.kernel.org/stable/c/f28bba37fe244889b81bb5c508d3f6e5c6e342c5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-26994
In the Linux kernel, the following vulnerability has been resolved: speakup: Avoid crash on very long word In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.
- https://git.kernel.org/stable/c/0d130158db29f5e0b3893154908cf618896450a8
- https://git.kernel.org/stable/c/0efb15c14c493263cb3a5f65f5ddfd4603d19a76
- https://git.kernel.org/stable/c/6401038acfa24cba9c28cce410b7505efadd0222
- https://git.kernel.org/stable/c/756c5cb7c09e537b87b5d3acafcb101b2ccf394f
- https://git.kernel.org/stable/c/89af25bd4b4bf6a71295f07e07a8ae7dc03c6595
- https://git.kernel.org/stable/c/8defb1d22ba0395b81feb963b96e252b097ba76f
- https://git.kernel.org/stable/c/8f6b62125befe1675446923e4171eac2c012959c
- https://git.kernel.org/stable/c/c8d2f34ea96ea3bce6ba2535f867f0d4ee3b22e1
- https://git.kernel.org/stable/c/0d130158db29f5e0b3893154908cf618896450a8
- https://git.kernel.org/stable/c/0efb15c14c493263cb3a5f65f5ddfd4603d19a76
- https://git.kernel.org/stable/c/6401038acfa24cba9c28cce410b7505efadd0222
- https://git.kernel.org/stable/c/756c5cb7c09e537b87b5d3acafcb101b2ccf394f
- https://git.kernel.org/stable/c/89af25bd4b4bf6a71295f07e07a8ae7dc03c6595
- https://git.kernel.org/stable/c/8defb1d22ba0395b81feb963b96e252b097ba76f
- https://git.kernel.org/stable/c/8f6b62125befe1675446923e4171eac2c012959c
- https://git.kernel.org/stable/c/c8d2f34ea96ea3bce6ba2535f867f0d4ee3b22e1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26996
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled. After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled. As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL. And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object. Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory. [function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm [function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established.
- https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93
- https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e
- https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7
- https://git.kernel.org/stable/c/7f67c2020cb08499c400abf0fc32c65e4d9a09ca
- https://git.kernel.org/stable/c/f356fd0cbd9c9cbd0854657a80d1608d0d732db3
- https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93
- https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e
- https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7
- https://git.kernel.org/stable/c/7f67c2020cb08499c400abf0fc32c65e4d9a09ca
- https://git.kernel.org/stable/c/f356fd0cbd9c9cbd0854657a80d1608d0d732db3
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-26997
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: host: Fix dereference issue in DDMA completion flow. Fixed variable dereference issue in DDMA completion flow.
- https://git.kernel.org/stable/c/257d313e37d66c3bcc87197fb5b8549129c45dfe
- https://git.kernel.org/stable/c/26fde0ea40dda1b08fad3bc0a43f122f6dd8bddf
- https://git.kernel.org/stable/c/55656b2afd5f1efcec4245f3e7e814c2a9ef53f6
- https://git.kernel.org/stable/c/75bf5e78b2a27cb1bca6fa826e3ab685015165e1
- https://git.kernel.org/stable/c/8a139fa44870e84ac228b7b76423a49610e5ba9a
- https://git.kernel.org/stable/c/8aa5c28ac65cb5e7f1b9c0c3238c00b661dd2b8c
- https://git.kernel.org/stable/c/9de10b59d16880a0a3ae2876c142fe54ce45d816
- https://git.kernel.org/stable/c/eed04fa96c48790c1cce73c8a248e9d460b088f8
- https://git.kernel.org/stable/c/257d313e37d66c3bcc87197fb5b8549129c45dfe
- https://git.kernel.org/stable/c/26fde0ea40dda1b08fad3bc0a43f122f6dd8bddf
- https://git.kernel.org/stable/c/55656b2afd5f1efcec4245f3e7e814c2a9ef53f6
- https://git.kernel.org/stable/c/75bf5e78b2a27cb1bca6fa826e3ab685015165e1
- https://git.kernel.org/stable/c/8a139fa44870e84ac228b7b76423a49610e5ba9a
- https://git.kernel.org/stable/c/8aa5c28ac65cb5e7f1b9c0c3238c00b661dd2b8c
- https://git.kernel.org/stable/c/9de10b59d16880a0a3ae2876c142fe54ce45d816
- https://git.kernel.org/stable/c/eed04fa96c48790c1cce73c8a248e9d460b088f8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-26998
In the Linux kernel, the following vulnerability has been resolved: serial: core: Clearing the circular buffer before NULLifying it The circular buffer is NULLified in uart_tty_port_shutdown() under the spin lock. However, the PM or other timer based callbacks may still trigger after this event without knowning that buffer pointer is not valid. Since the serial code is a bit inconsistent in checking the buffer state (some rely on the head-tail positions, some on the buffer pointer), it's better to have both aligned, i.e. buffer pointer to be NULL and head-tail possitions to be the same, meaning it's empty. This will prevent asynchronous calls to dereference NULL pointer as reported recently in 8250 case: BUG: kernel NULL pointer dereference, address: 00000cf5 Workqueue: pm pm_runtime_work EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809) ... ? serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809) __start_tx (drivers/tty/serial/8250/8250_port.c:1551) serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654) serial_port_runtime_suspend (include/linux/serial_core.h:667 drivers/tty/serial/serial_port.c:63) __rpm_callback (drivers/base/power/runtime.c:393) ? serial_port_remove (drivers/tty/serial/serial_port.c:50) rpm_suspend (drivers/base/power/runtime.c:447) The proposed change will prevent ->start_tx() to be called during suspend on shut down port.
- https://git.kernel.org/stable/c/7ae7104d54342433a3a73975f6569beefdd86350
- https://git.kernel.org/stable/c/9cf7ea2eeb745213dc2a04103e426b960e807940
- https://git.kernel.org/stable/c/bb1118905e875c111d7ccef9aee86ac5e4e7f985
- https://git.kernel.org/stable/c/7ae7104d54342433a3a73975f6569beefdd86350
- https://git.kernel.org/stable/c/9cf7ea2eeb745213dc2a04103e426b960e807940
- https://git.kernel.org/stable/c/bb1118905e875c111d7ccef9aee86ac5e4e7f985
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-26999
In the Linux kernel, the following vulnerability has been resolved: serial/pmac_zilog: Remove flawed mitigation for rx irq flood The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console: ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0 That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock already locked in pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port. Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below. A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. So I don't think this code is needed any more. Remove it.
- https://git.kernel.org/stable/c/1be3226445362bfbf461c92a5bcdb1723f2e4907
- https://git.kernel.org/stable/c/52aaf1ff14622a04148dbb9ccce6d9de5d534ea7
- https://git.kernel.org/stable/c/69a02273e288011b521ee7c1f3ab2c23fda633ce
- https://git.kernel.org/stable/c/7a3bbe41efa55323b6ea3c35fa15941d4dbecdef
- https://git.kernel.org/stable/c/ab86cf6f8d24e63e9aca23da5108af1aa5483928
- https://git.kernel.org/stable/c/bbaafbb4651fede8d3c3881601ecaa4f834f9d3f
- https://git.kernel.org/stable/c/ca09dfc3cfdf89e6af3ac24e1c6c0be5c575a729
- https://git.kernel.org/stable/c/d679c816929d62af51c8e6d7fc0e165c9412d2f3
- https://git.kernel.org/stable/c/1be3226445362bfbf461c92a5bcdb1723f2e4907
- https://git.kernel.org/stable/c/52aaf1ff14622a04148dbb9ccce6d9de5d534ea7
- https://git.kernel.org/stable/c/69a02273e288011b521ee7c1f3ab2c23fda633ce
- https://git.kernel.org/stable/c/7a3bbe41efa55323b6ea3c35fa15941d4dbecdef
- https://git.kernel.org/stable/c/ab86cf6f8d24e63e9aca23da5108af1aa5483928
- https://git.kernel.org/stable/c/bbaafbb4651fede8d3c3881601ecaa4f834f9d3f
- https://git.kernel.org/stable/c/ca09dfc3cfdf89e6af3ac24e1c6c0be5c575a729
- https://git.kernel.org/stable/c/d679c816929d62af51c8e6d7fc0e165c9412d2f3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-27000
In the Linux kernel, the following vulnerability has been resolved: serial: mxs-auart: add spinlock around changing cts state The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board. [ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth] (...) [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4 [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210 (...)
- https://git.kernel.org/stable/c/0dc0637e6b16158af85945425821bfd0151adb37
- https://git.kernel.org/stable/c/21535ef0ac1945080198fe3e4347ea498205c99a
- https://git.kernel.org/stable/c/2c9b943e9924cf1269e44289bc5e60e51b0f5270
- https://git.kernel.org/stable/c/479244d68f5d94f3903eced52b093c1e01ddb495
- https://git.kernel.org/stable/c/54c4ec5f8c471b7c1137a1f769648549c423c026
- https://git.kernel.org/stable/c/56434e295bd446142025913bfdf1587f5e1970ad
- https://git.kernel.org/stable/c/5f40fd6ca2cf0bfbc5a5c9e403dfce8ca899ba37
- https://git.kernel.org/stable/c/94b0e65c75f4af888ab2dd6c90f060f762924e86
- https://git.kernel.org/stable/c/0dc0637e6b16158af85945425821bfd0151adb37
- https://git.kernel.org/stable/c/21535ef0ac1945080198fe3e4347ea498205c99a
- https://git.kernel.org/stable/c/2c9b943e9924cf1269e44289bc5e60e51b0f5270
- https://git.kernel.org/stable/c/479244d68f5d94f3903eced52b093c1e01ddb495
- https://git.kernel.org/stable/c/54c4ec5f8c471b7c1137a1f769648549c423c026
- https://git.kernel.org/stable/c/56434e295bd446142025913bfdf1587f5e1970ad
- https://git.kernel.org/stable/c/5f40fd6ca2cf0bfbc5a5c9e403dfce8ca899ba37
- https://git.kernel.org/stable/c/94b0e65c75f4af888ab2dd6c90f060f762924e86
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-27001
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things
can fall through the cracks. Depending on the hardware model,
URBs can have either bulk or interrupt type, and current version
of vmk80xx_find_usb_endpoints() function does not take that fully
into account. While this warning does not seem to be too harmful,
at the very least it will crash systems with 'panic_on_warn' set on
them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the
endpoint checking process with usb_find_common_endpoints() and
ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
...
Call Trace:
- https://git.kernel.org/stable/c/3a63ae0348d990e137cca04eced5b08379969ea9
- https://git.kernel.org/stable/c/59f33af9796160f851641d960bd93937f282c696
- https://git.kernel.org/stable/c/6ec3514a7d35ad9cfab600187612c29f669069d2
- https://git.kernel.org/stable/c/a3b8ae7e9297dd453f2977b011c5bc75eb20e71b
- https://git.kernel.org/stable/c/ac882d6b21bffecb57bcc4486701239eef5aa67b
- https://git.kernel.org/stable/c/b0b268eeb087e324ef3ea71f8e6cabd07630517f
- https://git.kernel.org/stable/c/d1718530e3f640b7d5f0050e725216eab57a85d8
- https://git.kernel.org/stable/c/f15370e315976198f338b41611f37ce82af6cf54
- https://git.kernel.org/stable/c/3a63ae0348d990e137cca04eced5b08379969ea9
- https://git.kernel.org/stable/c/59f33af9796160f851641d960bd93937f282c696
- https://git.kernel.org/stable/c/6ec3514a7d35ad9cfab600187612c29f669069d2
- https://git.kernel.org/stable/c/a3b8ae7e9297dd453f2977b011c5bc75eb20e71b
- https://git.kernel.org/stable/c/ac882d6b21bffecb57bcc4486701239eef5aa67b
- https://git.kernel.org/stable/c/b0b268eeb087e324ef3ea71f8e6cabd07630517f
- https://git.kernel.org/stable/c/d1718530e3f640b7d5f0050e725216eab57a85d8
- https://git.kernel.org/stable/c/f15370e315976198f338b41611f37ce82af6cf54
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27002
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: Do a runtime PM get on controllers during probe mt8183-mfgcfg has a mutual dependency with genpd during the probing stage, which leads to a deadlock in the following call stack: CPU0: genpd_lock --> clk_prepare_lock genpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock() CPU1: clk_prepare_lock --> genpd_lock clk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock() Do a runtime PM get at the probe function to make sure clk_register() won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg, do this on all mediatek clock controller probings because we don't believe this would cause any regression. Verified on MT8183 and MT8192 Chromebooks.
- https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8
- https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3
- https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5
- https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc
- https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8
- https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3
- https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5
- https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27003
In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree for clk_summary Similar to the previous commit, we should make sure that all devices are runtime resumed before printing the clk_summary through debugfs. Failure to do so would result in a deadlock if the thread is resuming a device to print clk state and that device is also runtime resuming in another thread, e.g the screen is turning on and the display driver is starting up. We remove the calls to clk_pm_runtime_{get,put}() in this path because they're superfluous now that we know the devices are runtime resumed. This also squashes a bug where the return value of clk_pm_runtime_get() wasn't checked, leading to an RPM count underflow on error paths.
- https://git.kernel.org/stable/c/2c077fdfd09dffb31a890e5095c8ab205138a42e
- https://git.kernel.org/stable/c/83ada89e4a86e2b28ea2b5113c76d6dc7560a4d0
- https://git.kernel.org/stable/c/9d1e795f754db1ac3344528b7af0b17b8146f321
- https://git.kernel.org/stable/c/b457105309d388e4081c716cf7b81d517ff74db4
- https://git.kernel.org/stable/c/2c077fdfd09dffb31a890e5095c8ab205138a42e
- https://git.kernel.org/stable/c/83ada89e4a86e2b28ea2b5113c76d6dc7560a4d0
- https://git.kernel.org/stable/c/9d1e795f754db1ac3344528b7af0b17b8146f321
- https://git.kernel.org/stable/c/b457105309d388e4081c716cf7b81d517ff74db4
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-27004
In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree during disable_unused Doug reported [1] the following hung task: INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20 The first thread is walking the clk tree and calling clk_pm_runtime_get() to power on devices required to read the clk hardware via struct clk_ops::is_enabled(). This thread holds the clk prepare_lock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clk_prepare(), trying to grab the prepare_lock waiting on the first thread. This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held. Actually doing that is near impossible today because the global prepare_lock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again. Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---
- https://git.kernel.org/stable/c/115554862294397590088ba02f11f2aba6d5016c
- https://git.kernel.org/stable/c/253ab38d1ee652a596942156978a233970d185ba
- https://git.kernel.org/stable/c/4af115f1a20a3d9093586079206ee37c2ac55123
- https://git.kernel.org/stable/c/60ff482c4205a5aac3b0595ab794cfd62295dab5
- https://git.kernel.org/stable/c/a29ec0465dce0b871003698698ac6fa92c9a5034
- https://git.kernel.org/stable/c/a424e713e0cc33d4b969cfda25b9f46df4d7b5bc
- https://git.kernel.org/stable/c/e581cf5d216289ef292d1a4036d53ce90e122469
- https://git.kernel.org/stable/c/115554862294397590088ba02f11f2aba6d5016c
- https://git.kernel.org/stable/c/253ab38d1ee652a596942156978a233970d185ba
- https://git.kernel.org/stable/c/4af115f1a20a3d9093586079206ee37c2ac55123
- https://git.kernel.org/stable/c/60ff482c4205a5aac3b0595ab794cfd62295dab5
- https://git.kernel.org/stable/c/a29ec0465dce0b871003698698ac6fa92c9a5034
- https://git.kernel.org/stable/c/a424e713e0cc33d4b969cfda25b9f46df4d7b5bc
- https://git.kernel.org/stable/c/e581cf5d216289ef292d1a4036d53ce90e122469
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-23
CVE-2024-27005
In the Linux kernel, the following vulnerability has been resolved:
interconnect: Don't access req_list while it's being manipulated
The icc_lock mutex was split into separate icc_lock and icc_bw_lock
mutexes in [1] to avoid lockdep splats. However, this didn't adequately
protect access to icc_node::req_list.
The icc_set_bw() function will eventually iterate over req_list while
only holding icc_bw_lock, but req_list can be modified while only
holding icc_lock. This causes races between icc_set_bw(), of_icc_get(),
and icc_put().
Example A:
CPU0 CPU1
---- ----
icc_set_bw(path_a)
mutex_lock(&icc_bw_lock);
icc_put(path_b)
mutex_lock(&icc_lock);
aggregate_requests()
hlist_for_each_entry(r, ...
hlist_del(...
- https://git.kernel.org/stable/c/19ec82b3cad1abef2a929262b8c1528f4e0c192d
- https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6
- https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42
- https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1
- https://git.kernel.org/stable/c/fe549d8e976300d0dd75bd904eb216bed8b145e0
- https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6
- https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42
- https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-12-01
CVE-2024-27008
In the Linux kernel, the following vulnerability has been resolved: drm: nv04: Fix out of bounds access When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value. Utilize macros from 'enum nouveau_or' in calls instead of hardcoding. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/097c7918fcfa1dee233acfd1f3029f00c3bc8062
- https://git.kernel.org/stable/c/26212da39ee14a52c76a202c6ae5153a84f579a5
- https://git.kernel.org/stable/c/5050ae879a828d752b439e3827aac126709da6d1
- https://git.kernel.org/stable/c/5fd4b090304e450aa0e7cc9cc2b4873285c6face
- https://git.kernel.org/stable/c/6690cc2732e2a8d0eaca44dcbac032a4b0148042
- https://git.kernel.org/stable/c/c2b97f26f081ceec3298151481687071075a25cb
- https://git.kernel.org/stable/c/cf92bb778eda7830e79452c6917efa8474a30c1e
- https://git.kernel.org/stable/c/df0991da7db846f7fa4ec6740350f743d3b69b04
- https://git.kernel.org/stable/c/097c7918fcfa1dee233acfd1f3029f00c3bc8062
- https://git.kernel.org/stable/c/26212da39ee14a52c76a202c6ae5153a84f579a5
- https://git.kernel.org/stable/c/5050ae879a828d752b439e3827aac126709da6d1
- https://git.kernel.org/stable/c/5fd4b090304e450aa0e7cc9cc2b4873285c6face
- https://git.kernel.org/stable/c/6690cc2732e2a8d0eaca44dcbac032a4b0148042
- https://git.kernel.org/stable/c/c2b97f26f081ceec3298151481687071075a25cb
- https://git.kernel.org/stable/c/cf92bb778eda7830e79452c6917efa8474a30c1e
- https://git.kernel.org/stable/c/df0991da7db846f7fa4ec6740350f743d3b69b04
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27009
In the Linux kernel, the following vulnerability has been resolved: s390/cio: fix race condition during online processing A race condition exists in ccw_device_set_online() that can cause the online process to fail, leaving the affected device in an inconsistent state. As a result, subsequent attempts to set that device online fail with return code ENODEV. The problem occurs when a path verification request arrives after a wait for final device state completed, but before the result state is evaluated. Fix this by ensuring that the CCW-device lock is held between determining final state and checking result state. Note that since: commit 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers") path verification requests are much more likely to occur during boot, resulting in an increased chance of this race condition occurring.
- https://git.kernel.org/stable/c/2d8527f2f911fab84aec04df4788c0c23af3df48
- https://git.kernel.org/stable/c/2df56f4ea769ff81e51bbb05699989603bde9c49
- https://git.kernel.org/stable/c/3076b3c38a704e10df5e143c213653309d532538
- https://git.kernel.org/stable/c/559f3a6333397ab6cd4a696edd65a70b6be62c6e
- https://git.kernel.org/stable/c/a4234decd0fe429832ca81c4637be7248b88b49e
- https://git.kernel.org/stable/c/2d8527f2f911fab84aec04df4788c0c23af3df48
- https://git.kernel.org/stable/c/2df56f4ea769ff81e51bbb05699989603bde9c49
- https://git.kernel.org/stable/c/3076b3c38a704e10df5e143c213653309d532538
- https://git.kernel.org/stable/c/559f3a6333397ab6cd4a696edd65a70b6be62c6e
- https://git.kernel.org/stable/c/a4234decd0fe429832ca81c4637be7248b88b49e
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27013
In the Linux kernel, the following vulnerability has been resolved: tun: limit printing rate when illegal packet received by tun dev vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f
- https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421
- https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad
- https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3
- https://git.kernel.org/stable/c/52854101180beccdb9dc2077a3bea31b6ad48dfa
- https://git.kernel.org/stable/c/62e27ef18eb4f0d33bbae8e9ef56b99696a74713
- https://git.kernel.org/stable/c/68459b8e3ee554ce71878af9eb69659b9462c588
- https://git.kernel.org/stable/c/a50dbeca28acf7051dfa92786b85f704c75db6eb
- https://git.kernel.org/stable/c/f8bbc07ac535593139c875ffa19af924b1084540
- https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421
- https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad
- https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3
- https://git.kernel.org/stable/c/52854101180beccdb9dc2077a3bea31b6ad48dfa
- https://git.kernel.org/stable/c/62e27ef18eb4f0d33bbae8e9ef56b99696a74713
- https://git.kernel.org/stable/c/68459b8e3ee554ce71878af9eb69659b9462c588
- https://git.kernel.org/stable/c/a50dbeca28acf7051dfa92786b85f704c75db6eb
- https://git.kernel.org/stable/c/f8bbc07ac535593139c875ffa19af924b1084540
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27014
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the `priv->state_lock`, any scheduled
aRFS works are canceled using the `cancel_work_sync` function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the `state_lock` which is already acquired.
The worker acquires the lock to delete the rules if the state
is down, which is not the worker's responsibility since
disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is
enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
======================================================
WARNING: possible circular locking dependency detected
6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
------------------------------------------------------
ethtool/386089 is trying to acquire lock:
ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock:
ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}:
__mutex_lock+0x80/0xc90
arfs_handle_work+0x4b/0x3b0 [mlx5_core]
process_one_work+0x1dc/0x4a0
worker_thread+0x1bf/0x3c0
kthread+0xd7/0x100
ret_from_fork+0x2d/0x50
ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}:
__lock_acquire+0x17b4/0x2c80
lock_acquire+0xd0/0x2b0
__flush_work+0x7a/0x4e0
__cancel_work_timer+0x131/0x1c0
arfs_del_rules+0x143/0x1e0 [mlx5_core]
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
ethnl_set_channels+0x28f/0x3b0
ethnl_default_set_doit+0xec/0x240
genl_family_rcv_msg_doit+0xd0/0x120
genl_rcv_msg+0x188/0x2c0
netlink_rcv_skb+0x54/0x100
genl_rcv+0x24/0x40
netlink_unicast+0x1a1/0x270
netlink_sendmsg+0x214/0x460
__sock_sendmsg+0x38/0x60
__sys_sendto+0x113/0x170
__x64_sys_sendto+0x20/0x30
do_syscall_64+0x40/0xe0
entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock);
lock((work_completion)(&rule->arfs_work));
lock(&priv->state_lock);
lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089:
#0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
#1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240
#2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace:
CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc
- https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b
- https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b
- https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693
- https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc
- https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b
- https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b
- https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27015
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: incorrect pppoe tuple pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path.
- https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d
- https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27
- https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d
- https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56
- https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2
- https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d
- https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27
- https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d
- https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56
- https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27016
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: validate pppoe header Ensure there is sufficient room to access the protocol field of the PPPoe header. Validate it once before the flowtable lookup, then use a helper function to access protocol field.
- https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf
- https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7
- https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9
- https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163
- https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433
- https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf
- https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7
- https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9
- https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163
- https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27018
In the Linux kernel, the following vulnerability has been resolved:
netfilter: br_netfilter: skip conntrack input hook for promisc packets
For historical reasons, when bridge device is in promisc mode, packets
that are directed to the taps follow bridge input hook path. This patch
adds a workaround to reset conntrack for these packets.
Jianbo Liu reports warning splats in their test infrastructure where
cloned packets reach the br_netfilter input hook to confirm the
conntrack object.
Scratch one bit from BR_INPUT_SKB_CB to annotate that this packet has
reached the input hook because it is passed up to the bridge device to
reach the taps.
[ 57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+0x157/0x180 [br_netfilter]
[ 57.572749] Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_isc si ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5ctl mlx5_core
[ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19
[ 57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 57.576662] RIP: 0010:br_nf_local_in+0x157/0x180 [br_netfilter]
[ 57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1
[ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202
[ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000
[ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000
[ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003
[ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000
[ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800
[ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000
[ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0
[ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ 57.585440] Call Trace:
[ 57.585721]
- https://git.kernel.org/stable/c/3f59ac29dea0921637053908fe99268d157bbb9d
- https://git.kernel.org/stable/c/43193174510ea4f3ce09b796e559a2fd9f148615
- https://git.kernel.org/stable/c/751de2012eafa4d46d8081056761fa0e9cc8a178
- https://git.kernel.org/stable/c/b13db0d16bc7b2a52abcf5cb71334f63faa5dbd6
- https://git.kernel.org/stable/c/dceb683ab87ca3666a9bb5c0158528b646faedc4
- https://git.kernel.org/stable/c/3f59ac29dea0921637053908fe99268d157bbb9d
- https://git.kernel.org/stable/c/43193174510ea4f3ce09b796e559a2fd9f148615
- https://git.kernel.org/stable/c/751de2012eafa4d46d8081056761fa0e9cc8a178
- https://git.kernel.org/stable/c/b13db0d16bc7b2a52abcf5cb71334f63faa5dbd6
- https://git.kernel.org/stable/c/dceb683ab87ca3666a9bb5c0158528b646faedc4
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27019
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.
- https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920
- https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73
- https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e
- https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88
- https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484
- https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349
- https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920
- https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73
- https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e
- https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88
- https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484
- https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-11-04
CVE-2024-27020
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process.
- https://git.kernel.org/stable/c/01f1a678b05ade4b1248019c2dcca773aebbeb7f
- https://git.kernel.org/stable/c/0b6de00206adbbfc6373b3ae38d2a6f197987907
- https://git.kernel.org/stable/c/8d56bad42ac4c43c6c72ddd6a654a2628bf839c5
- https://git.kernel.org/stable/c/934e66e231cff2b18faa2c8aad0b8cec13957e05
- https://git.kernel.org/stable/c/939109c0a8e2a006a6cc8209e262d25065f4403a
- https://git.kernel.org/stable/c/a9ebf340d123ae12582210407f879d6a5a1bc25b
- https://git.kernel.org/stable/c/b38a133d37fa421c8447b383d788c9cc6f5cb34c
- https://git.kernel.org/stable/c/f969eb84ce482331a991079ab7a5c4dc3b7f89bf
- https://git.kernel.org/stable/c/01f1a678b05ade4b1248019c2dcca773aebbeb7f
- https://git.kernel.org/stable/c/0b6de00206adbbfc6373b3ae38d2a6f197987907
- https://git.kernel.org/stable/c/8d56bad42ac4c43c6c72ddd6a654a2628bf839c5
- https://git.kernel.org/stable/c/934e66e231cff2b18faa2c8aad0b8cec13957e05
- https://git.kernel.org/stable/c/939109c0a8e2a006a6cc8209e262d25065f4403a
- https://git.kernel.org/stable/c/a9ebf340d123ae12582210407f879d6a5a1bc25b
- https://git.kernel.org/stable/c/b38a133d37fa421c8447b383d788c9cc6f5cb34c
- https://git.kernel.org/stable/c/f969eb84ce482331a991079ab7a5c4dc3b7f89bf
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2026-04-11
CVE-2024-27022
In the Linux kernel, the following vulnerability has been resolved: fork: defer linking file vma until vma is fully initialized Thorvald reported a WARNING [1]. And the root cause is below race: CPU 1 CPU 2 fork hugetlbfs_fallocate dup_mmap hugetlbfs_punch_hole i_mmap_lock_write(mapping); vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. i_mmap_unlock_write(mapping); hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem! i_mmap_lock_write(mapping); hugetlb_vmdelete_list vma_interval_tree_foreach hugetlb_vma_trylock_write -- Vma_lock is cleared. tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! hugetlb_vma_unlock_write -- Vma_lock is assigned!!! i_mmap_unlock_write(mapping); hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside i_mmap_rwsem lock while vma lock can be used in the same time. Fix this by deferring linking file vma until vma is fully initialized. Those vmas should be initialized first before they can be used.
- https://git.kernel.org/stable/c/2e5cbab8ccbfc7d4a3d8a21d3c2a1f2c1aa29b5b
- https://git.kernel.org/stable/c/35e351780fa9d8240dd6f7e4f245f9ea37e96c19
- https://git.kernel.org/stable/c/abdb88dd272bbeb93efe01d8e0b7b17e24af3a34
- https://git.kernel.org/stable/c/04b0c41912349aff11a1bbaef6a722bd7fbb90ac
- https://git.kernel.org/stable/c/0c42f7e039aba3de6d7dbf92da708e2b2ecba557
- https://git.kernel.org/stable/c/35e351780fa9d8240dd6f7e4f245f9ea37e96c19
- https://git.kernel.org/stable/c/abdb88dd272bbeb93efe01d8e0b7b17e24af3a34
- https://git.kernel.org/stable/c/cec11fa2eb512ebe3a459c185f4aca1d44059bbf
- https://git.kernel.org/stable/c/dd782da470761077f4d1120e191f1a35787cda6e
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/
Modified: 2025-01-14
CVE-2024-27395
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix Use-After-Free in ovs_ct_exit Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal of ovs_ct_limit_exit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe.
- https://git.kernel.org/stable/c/2db9a8c0a01fa1c762c1e61a13c212c492752994
- https://git.kernel.org/stable/c/35880c3fa6f8fe281a19975d2992644588ca33d3
- https://git.kernel.org/stable/c/589523cf0b384164e445dd5db8d5b1bf97982424
- https://git.kernel.org/stable/c/5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2
- https://git.kernel.org/stable/c/9048616553c65e750d43846f225843ed745ec0d4
- https://git.kernel.org/stable/c/bca6fa2d9a9f560e6b89fd5190b05cc2f5d422c1
- https://git.kernel.org/stable/c/eaa5e164a2110d2fb9e16c8a29e4501882235137
- https://git.kernel.org/stable/c/edee0758747d7c219e29db9ed1d4eb33e8d32865
- https://git.kernel.org/stable/c/2db9a8c0a01fa1c762c1e61a13c212c492752994
- https://git.kernel.org/stable/c/35880c3fa6f8fe281a19975d2992644588ca33d3
- https://git.kernel.org/stable/c/589523cf0b384164e445dd5db8d5b1bf97982424
- https://git.kernel.org/stable/c/5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2
- https://git.kernel.org/stable/c/9048616553c65e750d43846f225843ed745ec0d4
- https://git.kernel.org/stable/c/bca6fa2d9a9f560e6b89fd5190b05cc2f5d422c1
- https://git.kernel.org/stable/c/eaa5e164a2110d2fb9e16c8a29e4501882235137
- https://git.kernel.org/stable/c/edee0758747d7c219e29db9ed1d4eb33e8d32865
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-14
CVE-2024-27396
In the Linux kernel, the following vulnerability has been resolved: net: gtp: Fix Use-After-Free in gtp_dellink Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of gtp_dellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe.
- https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58
- https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd
- https://git.kernel.org/stable/c/25a1c2d4b1fcf938356a9688a96a6456abd44b29
- https://git.kernel.org/stable/c/2aacd4de45477582993f8a8abb9505a06426bfb6
- https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff3660327c07
- https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7
- https://git.kernel.org/stable/c/cd957d1716ec979d8f5bf38fc659aeb9fdaa2474
- https://git.kernel.org/stable/c/f2a904107ee2b647bb7794a1a82b67740d7c8a64
- https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58
- https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd
- https://git.kernel.org/stable/c/25a1c2d4b1fcf938356a9688a96a6456abd44b29
- https://git.kernel.org/stable/c/2aacd4de45477582993f8a8abb9505a06426bfb6
- https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff3660327c07
- https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7
- https://git.kernel.org/stable/c/cd957d1716ec979d8f5bf38fc659aeb9fdaa2474
- https://git.kernel.org/stable/c/f2a904107ee2b647bb7794a1a82b67740d7c8a64
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-30
CVE-2024-35847
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent double free on error The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ]
- https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792
- https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fea618137
- https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438
- https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52
- https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662
- https://git.kernel.org/stable/c/c26591afd33adce296c022e3480dea4282b7ef91
- https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9
- https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae
- https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792
- https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fea618137
- https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438
- https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52
- https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662
- https://git.kernel.org/stable/c/c26591afd33adce296c022e3480dea4282b7ef91
- https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9
- https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-03
CVE-2024-35849
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix information leak in btrfs_ioctl_logical_to_ino() Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000 This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory. Fix this by using kvzalloc() which zeroes out the memory on allocation.
- https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf
- https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6
- https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc
- https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772
- https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86
- https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6
- https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d
- https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54
- https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf
- https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6
- https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc
- https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772
- https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86
- https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6
- https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d
- https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-30
CVE-2024-35850
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NULL-deref on non-serdev setup Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when setup() is called for a non-serdev controller.
- https://git.kernel.org/stable/c/67459f1a707aae6d590454de07956c2752e21ea4
- https://git.kernel.org/stable/c/7ddb9de6af0f1c71147785b12fd7c8ec3f06cc86
- https://git.kernel.org/stable/c/bec4d4c6fa5c6526409f582e4f31144e20c86c21
- https://git.kernel.org/stable/c/67459f1a707aae6d590454de07956c2752e21ea4
- https://git.kernel.org/stable/c/7ddb9de6af0f1c71147785b12fd7c8ec3f06cc86
- https://git.kernel.org/stable/c/bec4d4c6fa5c6526409f582e4f31144e20c86c21
Modified: 2024-12-30
CVE-2024-35851
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NULL-deref on non-serdev suspend Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when wakeup() is called for a non-serdev controller during suspend. Just return true for now to restore the original behaviour and address the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") that causes the crash to happen already at setup() time.
- https://git.kernel.org/stable/c/52f9041deaca3fc5c40ef3b9cb943993ec7d2489
- https://git.kernel.org/stable/c/6b47cdeb786c38e4174319218db3fa6d7b4bba88
- https://git.kernel.org/stable/c/73e87c0a49fda31d7b589edccf4c72e924411371
- https://git.kernel.org/stable/c/b64092d2f108f0cd1d7fd7e176f5fb2a67a2f189
- https://git.kernel.org/stable/c/e60502b907be350c518819297b565007a94c706d
- https://git.kernel.org/stable/c/52f9041deaca3fc5c40ef3b9cb943993ec7d2489
- https://git.kernel.org/stable/c/6b47cdeb786c38e4174319218db3fa6d7b4bba88
- https://git.kernel.org/stable/c/73e87c0a49fda31d7b589edccf4c72e924411371
- https://git.kernel.org/stable/c/b64092d2f108f0cd1d7fd7e176f5fb2a67a2f189
- https://git.kernel.org/stable/c/e60502b907be350c518819297b565007a94c706d
Modified: 2024-12-30
CVE-2024-35852
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work The rehash delayed work is rescheduled with a delay if the number of credits at end of the work is not negative as supposedly it means that the migration ended. Otherwise, it is rescheduled immediately. After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash" the above is no longer accurate as a non-negative number of credits is no longer indicative of the migration being done. It can also happen if the work encountered an error in which case the migration will resume the next time the work is scheduled. The significance of the above is that it is possible for the work to be pending and associated with hints that were allocated when the migration started. This leads to the hints being leaked [1] when the work is canceled while pending as part of ACL region dismantle. Fix by freeing the hints if hints are associated with a work that was canceled while pending. Blame the original commit since the reliance on not having a pending work associated with hints is fragile. [1] unreferenced object 0xffff88810e7c3000 (size 256): comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9): [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0 [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390 [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400 [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160 [<00000000e81fd734>] process_one_work+0x59c/0xf20 [<00000000ceee9e81>] worker_thread+0x799/0x12c0 [<00000000bda6fe39>] kthread+0x246/0x300 [<0000000070056d23>] ret_from_fork+0x34/0x70 [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30
- https://git.kernel.org/stable/c/51cefc9da400b953fee749c9e5d26cd4a2b5d758
- https://git.kernel.org/stable/c/5bfe7bf9656ed2633718388f12b7c38b86414a04
- https://git.kernel.org/stable/c/63d814d93c5cce4c18284adc810028f28dca493f
- https://git.kernel.org/stable/c/857ed800133ffcfcee28582090b63b0cbb8ba59d
- https://git.kernel.org/stable/c/d72dd6fcd7886d0523afbab8b4a4b22d17addd7d
- https://git.kernel.org/stable/c/de1aaefa75be9d0ec19c9a3e0e2f9696de20c6ab
- https://git.kernel.org/stable/c/fb4e2b70a7194b209fc7320bbf33b375f7114bd5
- https://git.kernel.org/stable/c/51cefc9da400b953fee749c9e5d26cd4a2b5d758
- https://git.kernel.org/stable/c/5bfe7bf9656ed2633718388f12b7c38b86414a04
- https://git.kernel.org/stable/c/63d814d93c5cce4c18284adc810028f28dca493f
- https://git.kernel.org/stable/c/857ed800133ffcfcee28582090b63b0cbb8ba59d
- https://git.kernel.org/stable/c/d72dd6fcd7886d0523afbab8b4a4b22d17addd7d
- https://git.kernel.org/stable/c/de1aaefa75be9d0ec19c9a3e0e2f9696de20c6ab
- https://git.kernel.org/stable/c/fb4e2b70a7194b209fc7320bbf33b375f7114bd5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-07
CVE-2024-35853
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
The rehash delayed work migrates filters from one region to another.
This is done by iterating over all chunks (all the filters with the same
priority) in the region and in each chunk iterating over all the
filters.
If the migration fails, the code tries to migrate the filters back to
the old region. However, the rollback itself can also fail in which case
another migration will be erroneously performed. Besides the fact that
this ping pong is not a very good idea, it also creates a problem.
Each virtual chunk references two chunks: The currently used one
('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the
first holds the chunk we want to migrate filters to and the second holds
the chunk we are migrating filters from.
The code currently assumes - but does not verify - that the backup chunk
does not exist (NULL) if the currently used chunk does not reference the
target region. This assumption breaks when we are trying to rollback a
rollback, resulting in the backup chunk being overwritten and leaked
[1].
Fix by not rolling back a failed rollback and add a warning to avoid
future cases.
[1]
WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20
Modules linked in:
CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:parman_destroy+0x17/0x20
[...]
Call Trace:
- https://git.kernel.org/stable/c/0ae8ff7b6d42e33943af462910bdcfa2ec0cb8cf
- https://git.kernel.org/stable/c/413a01886c3958d4b8aac23a3bff3d430b92093e
- https://git.kernel.org/stable/c/617e98ba4c50f4547c9eb0946b1cfc26937d70d1
- https://git.kernel.org/stable/c/8ca3f7a7b61393804c46f170743c3b839df13977
- https://git.kernel.org/stable/c/b3fd51f684a0711504f82de510da109ae639722d
- https://git.kernel.org/stable/c/b822644fd90992ee362c5e0c8d2556efc8856c76
- https://git.kernel.org/stable/c/c6f3fa7f5a748bf6e5c4eb742686d6952f854e76
- https://git.kernel.org/stable/c/0ae8ff7b6d42e33943af462910bdcfa2ec0cb8cf
- https://git.kernel.org/stable/c/413a01886c3958d4b8aac23a3bff3d430b92093e
- https://git.kernel.org/stable/c/617e98ba4c50f4547c9eb0946b1cfc26937d70d1
- https://git.kernel.org/stable/c/8ca3f7a7b61393804c46f170743c3b839df13977
- https://git.kernel.org/stable/c/b3fd51f684a0711504f82de510da109ae639722d
- https://git.kernel.org/stable/c/b822644fd90992ee362c5e0c8d2556efc8856c76
- https://git.kernel.org/stable/c/c6f3fa7f5a748bf6e5c4eb742686d6952f854e76
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-07
CVE-2024-35854
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
The rehash delayed work migrates filters from one region to another
according to the number of available credits.
The migrated from region is destroyed at the end of the work if the
number of credits is non-negative as the assumption is that this is
indicative of migration being complete. This assumption is incorrect as
a non-negative number of credits can also be the result of a failed
migration.
The destruction of a region that still has filters referencing it can
result in a use-after-free [1].
Fix by not destroying the region if migration failed.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858
CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
Call Trace:
- https://git.kernel.org/stable/c/311eeaa7b9e26aba5b3d57b09859f07d8e9fc049
- https://git.kernel.org/stable/c/4c89642ca47fb620914780c7c51d8d1248201121
- https://git.kernel.org/stable/c/54225988889931467a9b55fdbef534079b665519
- https://git.kernel.org/stable/c/813e2ab753a8f8c243a39ede20c2e0adc15f3887
- https://git.kernel.org/stable/c/a02687044e124f8ccb427cd3632124a4e1a7d7c1
- https://git.kernel.org/stable/c/a429a912d6c779807f4d72a6cc0a1efaaa3613e1
- https://git.kernel.org/stable/c/e118e7ea24d1392878ef85926627c6bc640c4388
- https://git.kernel.org/stable/c/311eeaa7b9e26aba5b3d57b09859f07d8e9fc049
- https://git.kernel.org/stable/c/4c89642ca47fb620914780c7c51d8d1248201121
- https://git.kernel.org/stable/c/54225988889931467a9b55fdbef534079b665519
- https://git.kernel.org/stable/c/813e2ab753a8f8c243a39ede20c2e0adc15f3887
- https://git.kernel.org/stable/c/a02687044e124f8ccb427cd3632124a4e1a7d7c1
- https://git.kernel.org/stable/c/a429a912d6c779807f4d72a6cc0a1efaaa3613e1
- https://git.kernel.org/stable/c/e118e7ea24d1392878ef85926627c6bc640c4388
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-30
CVE-2024-35855
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
The rule activity update delayed work periodically traverses the list of
configured rules and queries their activity from the device.
As part of this task it accesses the entry pointed by 'ventry->entry',
but this entry can be changed concurrently by the rehash delayed work,
leading to a use-after-free [1].
Fix by closing the race and perform the activity query under the
'vregion->lock' mutex.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work
Call Trace:
- https://git.kernel.org/stable/c/1b73f6e4ea770410a937a8db98f77e52594d23a0
- https://git.kernel.org/stable/c/79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4
- https://git.kernel.org/stable/c/b183b915beef818a25e3154d719ca015a1ae0770
- https://git.kernel.org/stable/c/b996e8699da810e4c915841d6aaef761007f933a
- https://git.kernel.org/stable/c/c17976b42d546ee118ca300db559630ee96fb758
- https://git.kernel.org/stable/c/e24d2487424779c02760ff50cd9021b8676e19ef
- https://git.kernel.org/stable/c/feabdac2057e863d0e140a2adf3d232eb4882db4
- https://git.kernel.org/stable/c/1b73f6e4ea770410a937a8db98f77e52594d23a0
- https://git.kernel.org/stable/c/79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4
- https://git.kernel.org/stable/c/b183b915beef818a25e3154d719ca015a1ae0770
- https://git.kernel.org/stable/c/b996e8699da810e4c915841d6aaef761007f933a
- https://git.kernel.org/stable/c/c17976b42d546ee118ca300db559630ee96fb758
- https://git.kernel.org/stable/c/e24d2487424779c02760ff50cd9021b8676e19ef
- https://git.kernel.org/stable/c/feabdac2057e863d0e140a2adf3d232eb4882db4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-30
CVE-2024-35856
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: Fix double free of skb in coredump
hci_devcd_append() would free the skb on error so the caller don't
have to free it again otherwise it would cause the double free of skb.
Reported-by : Dan Carpenter
- https://git.kernel.org/stable/c/18bdb386a1a30e7a3d7732a98e45e69cf6b5710d
- https://git.kernel.org/stable/c/80dfef128cb9f1b1ef67c0fe8c8deb4ea7ad30c1
- https://git.kernel.org/stable/c/e20093c741d8da9f6390dd45d75b779861547035
- https://git.kernel.org/stable/c/18bdb386a1a30e7a3d7732a98e45e69cf6b5710d
- https://git.kernel.org/stable/c/80dfef128cb9f1b1ef67c0fe8c8deb4ea7ad30c1
- https://git.kernel.org/stable/c/e20093c741d8da9f6390dd45d75b779861547035
Modified: 2025-04-07
CVE-2024-35857
In the Linux kernel, the following vulnerability has been resolved:
icmp: prevent possible NULL dereferences from icmp_build_probe()
First problem is a double call to __in_dev_get_rcu(), because
the second one could return NULL.
if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list)
Second problem is a read from dev->ip6_ptr with no NULL check:
if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))
Use the correct RCU API to fix these.
v2: add missing include
- https://git.kernel.org/stable/c/23b7ee4a8d559bf38eac7ce5bb2f6ebf76f9c401
- https://git.kernel.org/stable/c/3e2979bf080c40da4f7c93aff8575ab8bc62b767
- https://git.kernel.org/stable/c/599c9ad5e1d43f5c12d869f5fd406ba5d8c55270
- https://git.kernel.org/stable/c/c58e88d49097bd12dfcfef4f075b43f5d5830941
- https://git.kernel.org/stable/c/d68dc711d84fdcf698e5d45308c3ddeede586350
- https://git.kernel.org/stable/c/23b7ee4a8d559bf38eac7ce5bb2f6ebf76f9c401
- https://git.kernel.org/stable/c/3e2979bf080c40da4f7c93aff8575ab8bc62b767
- https://git.kernel.org/stable/c/599c9ad5e1d43f5c12d869f5fd406ba5d8c55270
- https://git.kernel.org/stable/c/c58e88d49097bd12dfcfef4f075b43f5d5830941
- https://git.kernel.org/stable/c/d68dc711d84fdcf698e5d45308c3ddeede586350
Modified: 2024-12-30
CVE-2024-35858
In the Linux kernel, the following vulnerability has been resolved: net: bcmasp: fix memory leak when bringing down interface When bringing down the TX rings we flush the rings but forget to reclaimed the flushed packets. This leads to a memory leak since we do not free the dma mapped buffers. This also leads to tx control block corruption when bringing down the interface for power management.
- https://git.kernel.org/stable/c/09040baf8779ad880e0e0d0ea10e57aa929ef3ab
- https://git.kernel.org/stable/c/2389ad1990163d29cba5480d693b4c2e31cc545c
- https://git.kernel.org/stable/c/9f898fc2c31fbf0ac5ecd289f528a716464cb005
- https://git.kernel.org/stable/c/09040baf8779ad880e0e0d0ea10e57aa929ef3ab
- https://git.kernel.org/stable/c/2389ad1990163d29cba5480d693b4c2e31cc545c
- https://git.kernel.org/stable/c/9f898fc2c31fbf0ac5ecd289f528a716464cb005
Modified: 2025-11-18
CVE-2024-35869
In the Linux kernel, the following vulnerability has been resolved: smb: client: guarantee refcounted children from parent session Avoid potential use-after-free bugs when walking DFS referrals, mounting and performing DFS failover by ensuring that all children from parent @tcon->ses are also refcounted. They're all needed across the entire DFS mount. Get rid of @tcon->dfs_ses_list while we're at it, too.
- https://git.kernel.org/stable/c/062a7f0ff46eb57aff526897bd2bebfdb1d3046a
- https://git.kernel.org/stable/c/645f332c6b63499cc76197f9b6bffcc659ba64cc
- https://git.kernel.org/stable/c/e1db9ae87b7148c021daee1fcc4bc71b2ac58a79
- https://git.kernel.org/stable/c/062a7f0ff46eb57aff526897bd2bebfdb1d3046a
- https://git.kernel.org/stable/c/645f332c6b63499cc76197f9b6bffcc659ba64cc
- https://git.kernel.org/stable/c/e1db9ae87b7148c021daee1fcc4bc71b2ac58a79
Modified: 2025-11-03
CVE-2024-35870
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in smb2_reconnect_server()
The UAF bug is due to smb2_reconnect_server() accessing a session that
is already being teared down by another thread that is executing
__cifs_put_smb_ses(). This can happen when (a) the client has
connection to the server but no session or (b) another thread ends up
setting @ses->ses_status again to something different than
SES_EXITING.
To fix this, we need to make sure to unconditionally set
@ses->ses_status to SES_EXITING and prevent any other threads from
setting a new status while we're still tearing it down.
The following can be reproduced by adding some delay to right after
the ipc is freed in __cifs_put_smb_ses() - which will give
smb2_reconnect_server() worker a chance to run and then accessing
@ses->ipc:
kinit ...
mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10
[disconnect srv]
ls /mnt/1 &>/dev/null
sleep 30
kdestroy
[reconnect srv]
sleep 10
umount /mnt/1
...
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
04/01/2014
Workqueue: cifsiod smb2_reconnect_server [cifs]
RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0
Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad
de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75
7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8
RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83
RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800
RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000
R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000
FS: 0000000000000000(0000) GS:ffff888157c00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/24a9799aa8efecd0eb55a75e35f9d8e6400063aa
- https://git.kernel.org/stable/c/45f2beda1f1bc3d962ec07db1ccc3197c25499a5
- https://git.kernel.org/stable/c/6202996a1c1887e83d0b3b0fcd86d0e5e6910ea0
- https://git.kernel.org/stable/c/755fe68cd4b59e1d2a2dd3286177fd4404f57fed
- https://git.kernel.org/stable/c/24a9799aa8efecd0eb55a75e35f9d8e6400063aa
- https://git.kernel.org/stable/c/45f2beda1f1bc3d962ec07db1ccc3197c25499a5
- https://git.kernel.org/stable/c/6202996a1c1887e83d0b3b0fcd86d0e5e6910ea0
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
Modified: 2025-01-16
CVE-2024-35980
In the Linux kernel, the following vulnerability has been resolved: arm64: tlb: Fix TLBI RANGE operand KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty pages are collected by VMM and the page table entries become write protected during live migration. Unfortunately, the operand passed to the TLBI RANGE instruction isn't correctly sorted out due to the commit 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()"). It leads to crash on the destination VM after live migration because TLBs aren't flushed completely and some of the dirty pages are missed. For example, I have a VM where 8GB memory is assigned, starting from 0x40000000 (1GB). Note that the host has 4KB as the base page size. In the middile of migration, kvm_tlb_flush_vmid_range() is executed to flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to __kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3 and NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported by __TLBI_RANGE_NUM(). In this specific case, -1 has been returned from __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop in the __flush_tlb_range_op() until the variable @scale underflows and becomes -9, 0xffff708000040000 is set as the operand. The operand is wrong since it's sorted out by __TLBI_VADDR_RANGE() according to invalid @scale and @num. Fix it by extending __TLBI_RANGE_NUM() to support the combination of SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can be returned from the macro, meaning the TLBs for 0x200000 pages in the above example can be flushed in one shoot with SCALE#3 and NUM#31. The macro TLBI_RANGE_MASK is dropped since no one uses it any more. The comments are also adjusted accordingly.
- https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07
- https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa
- https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685
- https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07
- https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa
- https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685
Modified: 2025-01-16
CVE-2024-35981
In the Linux kernel, the following vulnerability has been resolved: virtio_net: Do not send RSS key if it is not supported There is a bug when setting the RSS options in virtio_net that can break the whole machine, getting the kernel into an infinite loop. Running the following command in any QEMU virtual machine with virtionet will reproduce this problem: # ethtool -X eth0 hfunc toeplitz This is how the problem happens: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_commit_rss_command() populates 4 entries for the rss scatter-gather 4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueue_map_desc() (QEMU function): if (!sz) { virtio_error(vdev, "virtio: zero sized buffers are not allowed"); 6) virtio_error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this crazy kernel. 8) The kernel is waiting for the response to come back (function virtnet_send_command()) 9) The kernel is waiting doing the following : while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueue_is_broken() does not look at the qemu `vdev->broken`, so, it never realizes that the vitio is broken at QEMU side. Fix it by not sending RSS commands if the feature is not available in the device.
- https://git.kernel.org/stable/c/059a49aa2e25c58f90b50151f109dd3c4cdb3a47
- https://git.kernel.org/stable/c/28e9a64638cd16bc1ecac9ff74ffeacb9fb652de
- https://git.kernel.org/stable/c/43a71c1b4b3a6d4db857b1435d271540279fc7de
- https://git.kernel.org/stable/c/539a2b995a4ed93125cb0efae0f793b00ab2158b
- https://git.kernel.org/stable/c/059a49aa2e25c58f90b50151f109dd3c4cdb3a47
- https://git.kernel.org/stable/c/28e9a64638cd16bc1ecac9ff74ffeacb9fb652de
- https://git.kernel.org/stable/c/43a71c1b4b3a6d4db857b1435d271540279fc7de
- https://git.kernel.org/stable/c/539a2b995a4ed93125cb0efae0f793b00ab2158b
Modified: 2025-01-16
CVE-2024-35983
In the Linux kernel, the following vulnerability has been resolved: bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS bits_per() rounds up to the next power of two when passed a power of two. This causes crashes on some machines and configurations.
- https://git.kernel.org/stable/c/15aa09d6d84629eb5296de30ac0aa19a33512f16
- https://git.kernel.org/stable/c/5af385f5f4cddf908f663974847a4083b2ff2c79
- https://git.kernel.org/stable/c/66297b2ceda841f809637731d287bda3a93b49d8
- https://git.kernel.org/stable/c/93ba36238db6a74a82feb3dc476e25ea424ad630
- https://git.kernel.org/stable/c/9b7c5004d7c5ae062134052a85290869a015814c
- https://git.kernel.org/stable/c/d34a516f2635090d36a306f84573e8de3d7374ce
- https://git.kernel.org/stable/c/ebfe41889b762f1933c6762f6624b9724a25bee0
- https://git.kernel.org/stable/c/15aa09d6d84629eb5296de30ac0aa19a33512f16
- https://git.kernel.org/stable/c/5af385f5f4cddf908f663974847a4083b2ff2c79
- https://git.kernel.org/stable/c/66297b2ceda841f809637731d287bda3a93b49d8
- https://git.kernel.org/stable/c/93ba36238db6a74a82feb3dc476e25ea424ad630
- https://git.kernel.org/stable/c/9b7c5004d7c5ae062134052a85290869a015814c
- https://git.kernel.org/stable/c/d34a516f2635090d36a306f84573e8de3d7374ce
- https://git.kernel.org/stable/c/ebfe41889b762f1933c6762f6624b9724a25bee0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-35984
In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions]
- https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d043702c83
- https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d
- https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde
- https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620
- https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec
- https://git.kernel.org/stable/c/91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f
- https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23
- https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85
- https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d043702c83
- https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d
- https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde
- https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620
- https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec
- https://git.kernel.org/stable/c/91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f
- https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23
- https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-16
CVE-2024-35985
In the Linux kernel, the following vulnerability has been resolved: sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf() It was possible to have pick_eevdf() return NULL, which then causes a NULL-deref. This turned out to be due to entity_eligible() returning falsely negative because of a s64 multiplcation overflow. Specifically, reweight_eevdf() computes the vlag without considering the limit placed upon vlag as update_entity_lag() does, and then the scaling multiplication (remember that weight is 20bit fixed point) can overflow. This then leads to the new vruntime being weird which then causes the above entity_eligible() to go side-ways and claim nothing is eligible. Thus limit the range of vlag accordingly. All this was quite rare, but fatal when it does happen.
- https://git.kernel.org/stable/c/06f27e6d7bf0abf54488259ef36bbf0e1fccb35c
- https://git.kernel.org/stable/c/1560d1f6eb6b398bddd80c16676776c0325fe5fe
- https://git.kernel.org/stable/c/470d347b14b0ecffa9b39cf8f644fa2351db3efb
- https://git.kernel.org/stable/c/06f27e6d7bf0abf54488259ef36bbf0e1fccb35c
- https://git.kernel.org/stable/c/1560d1f6eb6b398bddd80c16676776c0325fe5fe
- https://git.kernel.org/stable/c/470d347b14b0ecffa9b39cf8f644fa2351db3efb
Modified: 2025-04-04
CVE-2024-35986
In the Linux kernel, the following vulnerability has been resolved: phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered The power_supply frame-work is not really designed for there to be long living in kernel references to power_supply devices. Specifically unregistering a power_supply while some other code has a reference to it triggers a WARN in power_supply_unregister(): WARN_ON(atomic_dec_return(&psy->use_cnt)); Folllowed by the power_supply still getting removed and the backing data freed anyway, leaving the tusb1210 charger-detect code with a dangling reference, resulting in a crash the next time tusb1210_get_online() is called. Fix this by only holding the reference in tusb1210_get_online() freeing it at the end of the function. Note this still leaves a theoretical race window, but it avoids the issue when manually rmmod-ing the charger chip driver during development.
- https://git.kernel.org/stable/c/25b3498485ac281e5851700e33b97f12c9533fd8
- https://git.kernel.org/stable/c/73224a5d2180066c7fe05b4656647601ba08d588
- https://git.kernel.org/stable/c/9827caa5105fb16d1fae2e75c8d0e4662014b3ca
- https://git.kernel.org/stable/c/bf6e4ee5c43690e4c5a8a057bbcd4ff986bed052
- https://git.kernel.org/stable/c/25b3498485ac281e5851700e33b97f12c9533fd8
- https://git.kernel.org/stable/c/73224a5d2180066c7fe05b4656647601ba08d588
- https://git.kernel.org/stable/c/9827caa5105fb16d1fae2e75c8d0e4662014b3ca
- https://git.kernel.org/stable/c/bf6e4ee5c43690e4c5a8a057bbcd4ff986bed052
Modified: 2025-09-24
CVE-2024-35987
In the Linux kernel, the following vulnerability has been resolved: riscv: Fix loading 64-bit NOMMU kernels past the start of RAM commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") added logic to allow using RAM below the kernel load address. However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the kernel load address. Since that range of memory corresponds to PFNs below ARCH_PFN_OFFSET, mm initialization runs off the beginning of mem_map and corrupts adjacent kernel memory. Fix this by restoring the previous behavior for NOMMU kernels.
- https://git.kernel.org/stable/c/aea702dde7e9876fb00571a2602f25130847bf0f
- https://git.kernel.org/stable/c/b008e327fa570aca210f98c817757649bae56694
- https://git.kernel.org/stable/c/ea6628e4e2353978af7e3b4ad4fdaab6149acf3d
- https://git.kernel.org/stable/c/aea702dde7e9876fb00571a2602f25130847bf0f
- https://git.kernel.org/stable/c/b008e327fa570aca210f98c817757649bae56694
- https://git.kernel.org/stable/c/ea6628e4e2353978af7e3b4ad4fdaab6149acf3d
Modified: 2025-12-17
CVE-2024-35988
In the Linux kernel, the following vulnerability has been resolved: riscv: Fix TASK_SIZE on 64-bit NOMMU On NOMMU, userspace memory can come from anywhere in physical RAM. The current definition of TASK_SIZE is wrong if any RAM exists above 4G, causing spurious failures in the userspace access routines.
- https://git.kernel.org/stable/c/04bf2e5f95c1a52e28a7567a507f926efe31c3b6
- https://git.kernel.org/stable/c/4201b8c8f2c32af321fb50867e68ac6c1cbed4be
- https://git.kernel.org/stable/c/52e8a42b11078d2aad4b9ba96503d77c7299168b
- https://git.kernel.org/stable/c/6065e736f82c817c9a597a31ee67f0ce4628e948
- https://git.kernel.org/stable/c/a0f0dbbb1bc49fa0de18e92c36492ff6d804cdaa
- https://git.kernel.org/stable/c/efdcfa554b6eb228943ef1dd4d023c606be647d2
- https://git.kernel.org/stable/c/04bf2e5f95c1a52e28a7567a507f926efe31c3b6
- https://git.kernel.org/stable/c/4201b8c8f2c32af321fb50867e68ac6c1cbed4be
- https://git.kernel.org/stable/c/52e8a42b11078d2aad4b9ba96503d77c7299168b
- https://git.kernel.org/stable/c/6065e736f82c817c9a597a31ee67f0ce4628e948
- https://git.kernel.org/stable/c/a0f0dbbb1bc49fa0de18e92c36492ff6d804cdaa
- https://git.kernel.org/stable/c/efdcfa554b6eb228943ef1dd4d023c606be647d2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-35989
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
During the removal of the idxd driver, registered offline callback is
invoked as part of the clean up process. However, on systems with only
one CPU online, no valid target is available to migrate the
perf context, resulting in a kernel oops:
BUG: unable to handle page fault for address: 000000000002a2b8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 1470e1067 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
RIP: 0010:mutex_lock+0x2e/0x50
...
Call Trace:
- https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e
- https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb
- https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b
- https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be
- https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c
- https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e
- https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb
- https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b
- https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be
- https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c
Modified: 2024-11-21
CVE-2024-35990
In the Linux kernel, the following vulnerability has been resolved:
dma: xilinx_dpdma: Fix locking
There are several places where either chan->lock or chan->vchan.lock was
not held. Add appropriate locking. This fixes lockdep warnings like
[ 31.077578] ------------[ cut here ]------------
[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[ 31.077953] Modules linked in:
[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98
[ 31.078102] Hardware name: xlnx,zynqmp (DT)
[ 31.078169] Workqueue: events_unbound deferred_probe_work_func
[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0
[ 31.078550] sp : ffffffc083bb2e10
[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168
[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480
[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000
[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000
[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001
[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def
[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516
[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff
[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000
[ 31.080307] Call trace:
[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120
[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac
[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c
[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684
[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0
[ 31.081139] commit_tail+0x234/0x294
[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210
[ 31.081363] drm_atomic_commit+0x100/0x140
[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384
[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c
[ 31.081725] drm_client_modeset_commit+0x34/0x5c
[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168
[ 31.081899] drm_fb_helper_set_par+0x50/0x70
[ 31.081971] fbcon_init+0x538/0xc48
[ 31.082047] visual_init+0x16c/0x23c
[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634
[ 31.082320] do_take_over_console+0x24c/0x33c
[ 31.082429] do_fbcon_takeover+0xbc/0x1b0
[ 31.082503] fbcon_fb_registered+0x2d0/0x34c
[ 31.082663] register_framebuffer+0x27c/0x38c
[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c
[ 31.082939] drm_fb_helper_initial_config+0x50/0x74
[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108
[ 31.083115] drm_client_register+0xa0/0xf4
[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc
[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0
[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0
[ 31.083616] platform_probe+0x8c/0x13c
[ 31.083713] really_probe+0x258/0x59c
[ 31.083793] __driver_probe_device+0xc4/0x224
[ 31.083878] driver_probe_device+0x70/0x1c0
[ 31.083961] __device_attach_driver+0x108/0x1e0
[ 31.084052] bus_for_each_drv+0x9c/0x100
[ 31.084125] __device_attach+0x100/0x298
[ 31.084207] device_initial_probe+0x14/0x20
[ 31.084292] bus_probe_device+0xd8/0xdc
[ 31.084368] deferred_probe_work_func+0x11c/0x180
[ 31.084451] process_one_work+0x3ac/0x988
[ 31.084643] worker_thread+0x398/0x694
[ 31.084752] kthread+0x1bc/0x1c0
[ 31.084848] ret_from_fork+0x10/0x20
[ 31.084932] irq event stamp: 64549
[ 31.084970] hardirqs last enabled at (64548): [
- https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076
- https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38
- https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11
- https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b
- https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557
- https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de
- https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076
- https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38
- https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11
- https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b
- https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557
- https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-24
CVE-2024-35991
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
drain_workqueue() cannot be called safely in a spinlocked context due to
possible task rescheduling. In the multi-task scenario, calling
queue_work() while drain_workqueue() will lead to a Call Trace as
pushing a work on a draining workqueue is not permitted in spinlocked
context.
Call Trace:
- https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098
- https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f
- https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44
- https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098
- https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f
- https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44
Modified: 2024-11-21
CVE-2024-35992
In the Linux kernel, the following vulnerability has been resolved: phy: marvell: a3700-comphy: Fix out of bounds read There is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr' every iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'. Make sure 'gbe_phy_init[addr]' is used when all elements of 'gbe_phy_init_fix' array are handled. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/40406dfbc060503d2e0a9e637e98493c54997b3d
- https://git.kernel.org/stable/c/610f175d2e16fb2436ba7974b990563002c20d07
- https://git.kernel.org/stable/c/976df695f579bbb2914114b4e9974fe4ed1eb813
- https://git.kernel.org/stable/c/e4308bc22b9d46cf33165c9dfaeebcf29cd56f04
- https://git.kernel.org/stable/c/40406dfbc060503d2e0a9e637e98493c54997b3d
- https://git.kernel.org/stable/c/610f175d2e16fb2436ba7974b990563002c20d07
- https://git.kernel.org/stable/c/976df695f579bbb2914114b4e9974fe4ed1eb813
- https://git.kernel.org/stable/c/e4308bc22b9d46cf33165c9dfaeebcf29cd56f04
Modified: 2025-09-24
CVE-2024-35993
In the Linux kernel, the following vulnerability has been resolved: mm: turn folio_test_hugetlb into a PageType The current folio_test_hugetlb() can be fooled by a concurrent folio split into returning true for a folio which has never belonged to hugetlbfs. This can't happen if the caller holds a refcount on it, but we have a few places (memory-failure, compaction, procfs) which do not and should not take a speculative reference. Since hugetlb pages do not use individual page mapcounts (they are always fully mapped and use the entire_mapcount field to record the number of mappings), the PageType field is available now that page_mapcount() ignores the value in this field. In compaction and with CONFIG_DEBUG_VM enabled, the current implementation can result in an oops, as reported by Luis. This happens since 9c5ccf2db04b ("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks in the PageHuge() testing path. [willy@infradead.org: update vmcoreinfo]
- https://git.kernel.org/stable/c/2431b5f2650dfc47ce782d1ca7b02d6b3916976f
- https://git.kernel.org/stable/c/9fdcc5b6359dfdaa52a55033bf50e2cedd66eb32
- https://git.kernel.org/stable/c/d99e3140a4d33e26066183ff727d8f02f56bec64
- https://git.kernel.org/stable/c/2431b5f2650dfc47ce782d1ca7b02d6b3916976f
- https://git.kernel.org/stable/c/9fdcc5b6359dfdaa52a55033bf50e2cedd66eb32
- https://git.kernel.org/stable/c/d99e3140a4d33e26066183ff727d8f02f56bec64
Modified: 2025-09-24
CVE-2024-35995
In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Use access_width over bit_width for system memory accesses To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id. If access_width is not set, then fall back to using bit_width. [ rjw: Subject and changelog edits, comment adjustments ]
- https://git.kernel.org/stable/c/01fc53be672acae37e611c80cc0b4f3939584de3
- https://git.kernel.org/stable/c/1b890ae474d19800a6be1696df7fb4d9a41676e4
- https://git.kernel.org/stable/c/2f4a4d63a193be6fd530d180bb13c3592052904c
- https://git.kernel.org/stable/c/6cb6b12b78dcd8867a3fdbb1b6d0ed1df2b208d1
- https://git.kernel.org/stable/c/01fc53be672acae37e611c80cc0b4f3939584de3
- https://git.kernel.org/stable/c/1b890ae474d19800a6be1696df7fb4d9a41676e4
- https://git.kernel.org/stable/c/2f4a4d63a193be6fd530d180bb13c3592052904c
- https://git.kernel.org/stable/c/4949affd5288b867cdf115f5b08d6166b2027f87
- https://git.kernel.org/stable/c/6cb6b12b78dcd8867a3fdbb1b6d0ed1df2b208d1
- https://git.kernel.org/stable/c/6dfd79ed04c578f1d9a9a41ba5b2015cf9f03fc3
- https://git.kernel.org/stable/c/b54c4632946ae42f2b39ed38abd909bbf78cbcc2
Modified: 2025-12-17
CVE-2024-35996
In the Linux kernel, the following vulnerability has been resolved: cpu: Re-enable CPU mitigations by default for !X86 architectures Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is completely generic, whereas SPECULATION_MITIGATIONS is x86-specific. Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it select CPU_MITIGATIONS, as having two configs for the same thing is unnecessary and confusing. This will also allow x86 to use the knob to manage mitigations that aren't strictly related to speculative execution. Use another Kconfig to communicate to common code that CPU_MITIGATIONS is already defined instead of having x86's menu depend on the common CPU_MITIGATIONS. This allows keeping a single point of contact for all of x86's mitigations, and it's not clear that other architectures *want* to allow disabling mitigations at compile-time.
- https://git.kernel.org/stable/c/36b32816fbab267611f073223f1b0b816ec5920f
- https://git.kernel.org/stable/c/38f17d1fbb5bfb56ca1419e2d06376d57a9396f9
- https://git.kernel.org/stable/c/8292f4f8dd1b005d0688d726261004f816ef730a
- https://git.kernel.org/stable/c/af6d6a923b40bf6471e44067ac61cc5814b48e7f
- https://git.kernel.org/stable/c/fd8547ebc187037cc69441a15c1441aeaab80f49
- https://git.kernel.org/stable/c/fe42754b94a42d08cf9501790afc25c4f6a5f631
- https://git.kernel.org/stable/c/36b32816fbab267611f073223f1b0b816ec5920f
- https://git.kernel.org/stable/c/38f17d1fbb5bfb56ca1419e2d06376d57a9396f9
- https://git.kernel.org/stable/c/8292f4f8dd1b005d0688d726261004f816ef730a
- https://git.kernel.org/stable/c/af6d6a923b40bf6471e44067ac61cc5814b48e7f
- https://git.kernel.org/stable/c/fd8547ebc187037cc69441a15c1441aeaab80f49
- https://git.kernel.org/stable/c/fe42754b94a42d08cf9501790afc25c4f6a5f631
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-16
CVE-2024-35997
In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that. More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop. Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up. Delete this unnecessary flag.
- https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1
- https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401
- https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722
- https://git.kernel.org/stable/c/418c5575d56410c6e186ab727bf32ae32447d497
- https://git.kernel.org/stable/c/5095b93021b899f54c9355bebf36d78854c33a22
- https://git.kernel.org/stable/c/9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e
- https://git.kernel.org/stable/c/b65fb50e04a95eec34a9d1bc138454a98a5578d8
- https://git.kernel.org/stable/c/c448a9fd50f77e8fb9156ff64848aa4295eb3003
- https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1
- https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401
- https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722
- https://git.kernel.org/stable/c/418c5575d56410c6e186ab727bf32ae32447d497
- https://git.kernel.org/stable/c/5095b93021b899f54c9355bebf36d78854c33a22
- https://git.kernel.org/stable/c/9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e
- https://git.kernel.org/stable/c/b65fb50e04a95eec34a9d1bc138454a98a5578d8
- https://git.kernel.org/stable/c/c448a9fd50f77e8fb9156ff64848aa4295eb3003
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-01-10
CVE-2024-35998
In the Linux kernel, the following vulnerability has been resolved: smb3: fix lock ordering potential deadlock in cifs_sync_mid_result Coverity spotted that the cifs_sync_mid_result function could deadlock "Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock" Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")
- https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75
- https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc
- https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f
- https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66
- https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75
- https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc
- https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f
- https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66
Modified: 2025-04-04
CVE-2024-35999
In the Linux kernel, the following vulnerability has been resolved: smb3: missing lock when picking channel Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index. Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")
- https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e
- https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00
- https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887
- https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729
- https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e
- https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00
- https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887
- https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729
Modified: 2025-09-23
CVE-2024-36000
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix missing hugetlb_lock for resv uncharge There is a recent report on UFFDIO_COPY over hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held.
- https://git.kernel.org/stable/c/4c806333efea1000a2a9620926f560ad2e1ca7cc
- https://git.kernel.org/stable/c/538faabf31e9c53d8c870d114846fda958a0de10
- https://git.kernel.org/stable/c/b76b46902c2d0395488c8412e1116c2486cdfcb2
- https://git.kernel.org/stable/c/f6c5d21db16a0910152ec8aa9d5a7aed72694505
- https://git.kernel.org/stable/c/4c806333efea1000a2a9620926f560ad2e1ca7cc
- https://git.kernel.org/stable/c/538faabf31e9c53d8c870d114846fda958a0de10
- https://git.kernel.org/stable/c/b76b46902c2d0395488c8412e1116c2486cdfcb2
- https://git.kernel.org/stable/c/f6c5d21db16a0910152ec8aa9d5a7aed72694505
Modified: 2025-02-03
CVE-2024-36003
In the Linux kernel, the following vulnerability has been resolved:
ice: fix LAG and VF lock dependency in ice_reset_vf()
9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over
aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf().
The commit placed this lock acquisition just prior to the acquisition of
the VF configuration lock.
If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK
flag, this could deadlock with ice_vc_cfg_qs_msg() because it always
acquires the locks in the order of the VF configuration lock and then the
LAG mutex.
Lockdep reports this violation almost immediately on creating and then
removing 2 VF:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-rc6 #54 Tainted: G W O
------------------------------------------------------
kworker/60:3/6771 is trying to acquire lock:
ff40d43e099380a0 (&vf->cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]
but task is already holding lock:
ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&pf->lag_mutex){+.+.}-{3:3}:
__lock_acquire+0x4f8/0xb40
lock_acquire+0xd4/0x2d0
__mutex_lock+0x9b/0xbf0
ice_vc_cfg_qs_msg+0x45/0x690 [ice]
ice_vc_process_vf_msg+0x4f5/0x870 [ice]
__ice_clean_ctrlq+0x2b5/0x600 [ice]
ice_service_task+0x2c9/0x480 [ice]
process_one_work+0x1e9/0x4d0
worker_thread+0x1e1/0x3d0
kthread+0x104/0x140
ret_from_fork+0x31/0x50
ret_from_fork_asm+0x1b/0x30
-> #0 (&vf->cfg_lock){+.+.}-{3:3}:
check_prev_add+0xe2/0xc50
validate_chain+0x558/0x800
__lock_acquire+0x4f8/0xb40
lock_acquire+0xd4/0x2d0
__mutex_lock+0x9b/0xbf0
ice_reset_vf+0x22f/0x4d0 [ice]
ice_process_vflr_event+0x98/0xd0 [ice]
ice_service_task+0x1cc/0x480 [ice]
process_one_work+0x1e9/0x4d0
worker_thread+0x1e1/0x3d0
kthread+0x104/0x140
ret_from_fork+0x31/0x50
ret_from_fork_asm+0x1b/0x30
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&pf->lag_mutex);
lock(&vf->cfg_lock);
lock(&pf->lag_mutex);
lock(&vf->cfg_lock);
*** DEADLOCK ***
4 locks held by kworker/60:3/6771:
#0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0
#1: ff50d06e05197e58 ((work_completion)(&pf->serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0
#2: ff40d43ea1960e50 (&pf->vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]
#3: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
stack backtrace:
CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54
Hardware name:
Workqueue: ice ice_service_task [ice]
Call Trace:
- https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c
- https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f
- https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6
- https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c
- https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f
- https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6
Modified: 2025-12-17
CVE-2024-36004
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
Issue reported by customer during SRIOV testing, call trace:
When both i40e and the i40iw driver are loaded, a warning
in check_flush_dependency is being triggered. This seems
to be because of the i40e driver workqueue is allocated with
the WQ_MEM_RECLAIM flag, and the i40iw one is not.
Similar error was encountered on ice too and it was fixed by
removing the flag. Do the same for i40e too.
[Feb 9 09:08] ------------[ cut here ]------------
[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
flushing !WQ_MEM_RECLAIM infiniband:0x0
[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
check_flush_dependency+0x10b/0x120
[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
dm_region_hash dm_log dm_mod fuse
[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
SE5C620.86B.02.01.0013.121520200651 12/15/2020
[ +0.000001] Workqueue: i40e i40e_service_task [i40e]
[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
0000000000000027
[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
ffff94d47f620bc0
[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
00000000ffff7fff
[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
ffff94c5451ea180
[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
ffff94c5f1330ab0
[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)
knlGS:0000000000000000
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
00000000007706f0
[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ +0.000001] PKRU: 55555554
[ +0.000001] Call Trace:
[ +0.000001]
- https://git.kernel.org/stable/c/09b54d29f05129b092f7c793a70b689ffb3c7b2c
- https://git.kernel.org/stable/c/152ed360cf2d273f88fc99a518b7eb868aae2939
- https://git.kernel.org/stable/c/1594dac8b1ed78f9e75c263327e198a2e5e25b0e
- https://git.kernel.org/stable/c/2cc7d150550cc981aceedf008f5459193282425c
- https://git.kernel.org/stable/c/546d0fe9d76e8229a67369f9cb61e961d99038bd
- https://git.kernel.org/stable/c/8d6105f637883c8c09825e962308c06e977de4f0
- https://git.kernel.org/stable/c/fbbb2404340dd6178e281bd427c271f7d5ec1d22
- https://git.kernel.org/stable/c/ff7431f898dd00892a545b7d0ce7adf5b926944f
- https://git.kernel.org/stable/c/09b54d29f05129b092f7c793a70b689ffb3c7b2c
- https://git.kernel.org/stable/c/152ed360cf2d273f88fc99a518b7eb868aae2939
- https://git.kernel.org/stable/c/1594dac8b1ed78f9e75c263327e198a2e5e25b0e
- https://git.kernel.org/stable/c/2cc7d150550cc981aceedf008f5459193282425c
- https://git.kernel.org/stable/c/546d0fe9d76e8229a67369f9cb61e961d99038bd
- https://git.kernel.org/stable/c/8d6105f637883c8c09825e962308c06e977de4f0
- https://git.kernel.org/stable/c/fbbb2404340dd6178e281bd427c271f7d5ec1d22
- https://git.kernel.org/stable/c/ff7431f898dd00892a545b7d0ce7adf5b926944f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-36005
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: honor table dormant flag from netdev release event path
Check for table dormant flag otherwise netdev release event path tries
to unregister an already unregistered hook.
[524854.857999] ------------[ cut here ]------------
[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260
[...]
[524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365
[524854.858869] Workqueue: netns cleanup_net
[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260
[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41
[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246
[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a
[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438
[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34
[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005
[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00
[524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000
[524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0
[524854.859000] Call Trace:
[524854.859006]
- https://git.kernel.org/stable/c/13ba94f6cc820fdea15efeaa17d4c722874eebf9
- https://git.kernel.org/stable/c/5c45feb3c288cf44a529e2657b36c259d86497d2
- https://git.kernel.org/stable/c/8260c980aee7d8d8a3db39faf19c391d2f898816
- https://git.kernel.org/stable/c/8e30abc9ace4f0add4cd761dfdbfaebae5632dd2
- https://git.kernel.org/stable/c/ca34c40d1c22c555fa7f4a21a1c807fea7290a0a
- https://git.kernel.org/stable/c/e4bb6da24de336a7899033a65490ed2d892efa5b
- https://git.kernel.org/stable/c/13ba94f6cc820fdea15efeaa17d4c722874eebf9
- https://git.kernel.org/stable/c/5c45feb3c288cf44a529e2657b36c259d86497d2
- https://git.kernel.org/stable/c/8260c980aee7d8d8a3db39faf19c391d2f898816
- https://git.kernel.org/stable/c/8e30abc9ace4f0add4cd761dfdbfaebae5632dd2
- https://git.kernel.org/stable/c/ca34c40d1c22c555fa7f4a21a1c807fea7290a0a
- https://git.kernel.org/stable/c/e4bb6da24de336a7899033a65490ed2d892efa5b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-17
CVE-2024-36006
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
Both the function that migrates all the chunks within a region and the
function that migrates all the entries within a chunk call
list_first_entry() on the respective lists without checking that the
lists are not empty. This is incorrect usage of the API, which leads to
the following warning [1].
Fix by returning if the lists are empty as there is nothing to migrate
in this case.
[1]
WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0>
Modules linked in:
CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0
[...]
Call Trace:
- https://git.kernel.org/stable/c/09846c2309b150b8ce4e0ce96f058197598fc530
- https://git.kernel.org/stable/c/0b2c13b670b168e324e1cf109e67056a20fd610a
- https://git.kernel.org/stable/c/4526a56e02da3725db979358964df9cd9c567154
- https://git.kernel.org/stable/c/64435b64e43d8ee60faa46c0cd04e323e8b2a7b0
- https://git.kernel.org/stable/c/ab4ecfb627338e440ae11def004c524a00d93e40
- https://git.kernel.org/stable/c/af8b593c3dd9df82cb199be65863af004b09fd97
- https://git.kernel.org/stable/c/b377add0f0117409c418ddd6504bd682ebe0bf79
- https://git.kernel.org/stable/c/09846c2309b150b8ce4e0ce96f058197598fc530
- https://git.kernel.org/stable/c/0b2c13b670b168e324e1cf109e67056a20fd610a
- https://git.kernel.org/stable/c/4526a56e02da3725db979358964df9cd9c567154
- https://git.kernel.org/stable/c/64435b64e43d8ee60faa46c0cd04e323e8b2a7b0
- https://git.kernel.org/stable/c/ab4ecfb627338e440ae11def004c524a00d93e40
- https://git.kernel.org/stable/c/af8b593c3dd9df82cb199be65863af004b09fd97
- https://git.kernel.org/stable/c/b377add0f0117409c418ddd6504bd682ebe0bf79
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-17
CVE-2024-36007
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix warning during rehash
As previously explained, the rehash delayed work migrates filters from
one region to another. This is done by iterating over all chunks (all
the filters with the same priority) in the region and in each chunk
iterating over all the filters.
When the work runs out of credits it stores the current chunk and entry
as markers in the per-work context so that it would know where to resume
the migration from the next time the work is scheduled.
Upon error, the chunk marker is reset to NULL, but without resetting the
entry markers despite being relative to it. This can result in migration
being resumed from an entry that does not belong to the chunk being
migrated. In turn, this will eventually lead to a chunk being iterated
over as if it is an entry. Because of how the two structures happen to
be defined, this does not lead to KASAN splats, but to warnings such as
[1].
Fix by creating a helper that resets all the markers and call it from
all the places the currently only reset the chunk marker. For good
measures also call it when starting a completely new rehash. Add a
warning to avoid future cases.
[1]
WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0
Modules linked in:
CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_afk_encode+0x242/0x2f0
[...]
Call Trace:
- https://git.kernel.org/stable/c/039992b6d2df097c65f480dcf269de3d2656f573
- https://git.kernel.org/stable/c/0b88631855026b55cad901ac28d081e0f358e596
- https://git.kernel.org/stable/c/17e9e0bbae652b9b2049e51699e93dfa60b2988d
- https://git.kernel.org/stable/c/1d76bd2a0034d0d08045c1c6adf2235d88982952
- https://git.kernel.org/stable/c/743edc8547a92b6192aa1f1b6bb78233fa21dc9b
- https://git.kernel.org/stable/c/751d352858108314efd33dddd5a9a2b6bf7d6916
- https://git.kernel.org/stable/c/e890456051fe8c57944b911defb3e6de91315861
- https://git.kernel.org/stable/c/039992b6d2df097c65f480dcf269de3d2656f573
- https://git.kernel.org/stable/c/0b88631855026b55cad901ac28d081e0f358e596
- https://git.kernel.org/stable/c/17e9e0bbae652b9b2049e51699e93dfa60b2988d
- https://git.kernel.org/stable/c/1d76bd2a0034d0d08045c1c6adf2235d88982952
- https://git.kernel.org/stable/c/743edc8547a92b6192aa1f1b6bb78233fa21dc9b
- https://git.kernel.org/stable/c/751d352858108314efd33dddd5a9a2b6bf7d6916
- https://git.kernel.org/stable/c/e890456051fe8c57944b911defb3e6de91315861
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2024-36008
In the Linux kernel, the following vulnerability has been resolved: ipv4: check for NULL idev in ip_route_use_hint() syzbot was able to trigger a NULL deref in fib_validate_source() in an old tree [1]. It appears the bug exists in latest trees. All calls to __in_dev_get_rcu() must be checked for a NULL result. [1] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425 Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231 ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327 ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline] ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638 ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673 __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline] __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620 __netif_receive_skb_list net/core/dev.c:5672 [inline] netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764 netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816 xdp_recv_frames net/bpf/test_run.c:257 [inline] xdp_test_run_batch net/bpf/test_run.c:335 [inline] bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363 bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376 bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736 __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115 __do_sys_bpf kernel/bpf/syscall.c:5201 [inline] __se_sys_bpf kernel/bpf/syscall.c:5199 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199
- https://git.kernel.org/stable/c/03b5a9b2b526862b21bcc31976e393a6e63785d1
- https://git.kernel.org/stable/c/58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1
- https://git.kernel.org/stable/c/7a25bfd12733a8f38f8ca47c581f876c3d481ac0
- https://git.kernel.org/stable/c/7da0f91681c4902bc5c210356fdd963b04d5d1d4
- https://git.kernel.org/stable/c/8240c7308c941db4d9a0a91b54eca843c616a655
- https://git.kernel.org/stable/c/c71ea3534ec0936fc57e6fb271c7cc6a2f68c295
- https://git.kernel.org/stable/c/03b5a9b2b526862b21bcc31976e393a6e63785d1
- https://git.kernel.org/stable/c/58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1
- https://git.kernel.org/stable/c/7a25bfd12733a8f38f8ca47c581f876c3d481ac0
- https://git.kernel.org/stable/c/7da0f91681c4902bc5c210356fdd963b04d5d1d4
- https://git.kernel.org/stable/c/8240c7308c941db4d9a0a91b54eca843c616a655
- https://git.kernel.org/stable/c/c71ea3534ec0936fc57e6fb271c7cc6a2f68c295
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-23
CVE-2024-36009
In the Linux kernel, the following vulnerability has been resolved: ax25: Fix netdev refcount issue The dev_tracker is added to ax25_cb in ax25_bind(). When the ax25 device is detaching, the dev_tracker of ax25_cb should be deallocated in ax25_kill_by_device() instead of the dev_tracker of ax25_dev. The log reported by ref_tracker is shown below: [ 80.884935] ref_tracker: reference already released. [ 80.885150] ref_tracker: allocated in: [ 80.885349] ax25_dev_device_up+0x105/0x540 [ 80.885730] ax25_device_event+0xa4/0x420 [ 80.885730] notifier_call_chain+0xc9/0x1e0 [ 80.885730] __dev_notify_flags+0x138/0x280 [ 80.885730] dev_change_flags+0xd7/0x180 [ 80.885730] dev_ifsioc+0x6a9/0xa30 [ 80.885730] dev_ioctl+0x4d8/0xd90 [ 80.885730] sock_do_ioctl+0x1c2/0x2d0 [ 80.885730] sock_ioctl+0x38b/0x4f0 [ 80.885730] __se_sys_ioctl+0xad/0xf0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 80.885730] ref_tracker: freed in: [ 80.885730] ax25_device_event+0x272/0x420 [ 80.885730] notifier_call_chain+0xc9/0x1e0 [ 80.885730] dev_close_many+0x272/0x370 [ 80.885730] unregister_netdevice_many_notify+0x3b5/0x1180 [ 80.885730] unregister_netdev+0xcf/0x120 [ 80.885730] sixpack_close+0x11f/0x1b0 [ 80.885730] tty_ldisc_kill+0xcb/0x190 [ 80.885730] tty_ldisc_hangup+0x338/0x3d0 [ 80.885730] __tty_hangup+0x504/0x740 [ 80.885730] tty_release+0x46e/0xd80 [ 80.885730] __fput+0x37f/0x770 [ 80.885730] __x64_sys_close+0x7b/0xb0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 80.893739] ------------[ cut here ]------------ [ 80.894030] WARNING: CPU: 2 PID: 140 at lib/ref_tracker.c:255 ref_tracker_free+0x47b/0x6b0 [ 80.894297] Modules linked in: [ 80.894929] CPU: 2 PID: 140 Comm: ax25_conn_rel_6 Not tainted 6.9.0-rc4-g8cd26fd90c1a #11 [ 80.895190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qem4 [ 80.895514] RIP: 0010:ref_tracker_free+0x47b/0x6b0 [ 80.895808] Code: 83 c5 18 4c 89 eb 48 c1 eb 03 8a 04 13 84 c0 0f 85 df 01 00 00 41 83 7d 00 00 75 4b 4c 89 ff 9 [ 80.896171] RSP: 0018:ffff888009edf8c0 EFLAGS: 00000286 [ 80.896339] RAX: 1ffff1100141ac00 RBX: 1ffff1100149463b RCX: dffffc0000000000 [ 80.896502] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff88800a0d6518 [ 80.896925] RBP: ffff888009edf9b0 R08: ffff88806d3288d3 R09: 1ffff1100da6511a [ 80.897212] R10: dffffc0000000000 R11: ffffed100da6511b R12: ffff88800a4a31d4 [ 80.897859] R13: ffff88800a4a31d8 R14: dffffc0000000000 R15: ffff88800a0d6518 [ 80.898279] FS: 00007fd88b7fe700(0000) GS:ffff88806d300000(0000) knlGS:0000000000000000 [ 80.899436] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 80.900181] CR2: 00007fd88c001d48 CR3: 000000000993e000 CR4: 00000000000006f0 ... [ 80.935774] ref_tracker: sp%d@000000000bb9df3d has 1/1 users at [ 80.935774] ax25_bind+0x424/0x4e0 [ 80.935774] __sys_bind+0x1d9/0x270 [ 80.935774] __x64_sys_bind+0x75/0x80 [ 80.935774] do_syscall_64+0xc4/0x1b0 [ 80.935774] entry_SYSCALL_64_after_hwframe+0x67/0x6f Change ax25_dev->dev_tracker to the dev_tracker of ax25_cb in order to mitigate the bug.
- https://git.kernel.org/stable/c/0d14f104027e30720582448706c7d6b43065c851
- https://git.kernel.org/stable/c/467324bcfe1a31ec65d0cf4aa59421d6b7a7d52b
- https://git.kernel.org/stable/c/4fee8fa86a15d7790268eea458b1aec69c695530
- https://git.kernel.org/stable/c/c42b073d9af4a5329b25b17390c63ab3847f30e8
- http://www.openwall.com/lists/oss-security/2024/05/30/1
- http://www.openwall.com/lists/oss-security/2024/05/30/2
- https://git.kernel.org/stable/c/0d14f104027e30720582448706c7d6b43065c851
- https://git.kernel.org/stable/c/467324bcfe1a31ec65d0cf4aa59421d6b7a7d52b
- https://git.kernel.org/stable/c/4fee8fa86a15d7790268eea458b1aec69c695530
- https://git.kernel.org/stable/c/c42b073d9af4a5329b25b17390c63ab3847f30e8
Modified: 2025-09-30
CVE-2024-36029
In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-msm: pervent access to suspended controller Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.
- https://git.kernel.org/stable/c/1200481cd6069d16ce20133bcd86f5825e26a045
- https://git.kernel.org/stable/c/56b99a52229d7f8cd1f53d899f57aa7eb4b199af
- https://git.kernel.org/stable/c/a957ea5aa3d3518067a1ba32c6127322ad348d20
- https://git.kernel.org/stable/c/f653b04a818c490b045c97834d559911479aa1c5
- https://git.kernel.org/stable/c/f8def10f73a516b771051a2f70f2f0446902cb4f
- https://git.kernel.org/stable/c/1200481cd6069d16ce20133bcd86f5825e26a045
- https://git.kernel.org/stable/c/56b99a52229d7f8cd1f53d899f57aa7eb4b199af
- https://git.kernel.org/stable/c/a957ea5aa3d3518067a1ba32c6127322ad348d20
- https://git.kernel.org/stable/c/f653b04a818c490b045c97834d559911479aa1c5
- https://git.kernel.org/stable/c/f8def10f73a516b771051a2f70f2f0446902cb4f
Package kernel-modules-virtualbox-addition-std-def updated to version 7.0.18-alt1.393562.1 for branch sisyphus in task 347433.
Closed vulnerabilities
Modified: 2024-11-14
BDU:2024-03172
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03229
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии или выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03425
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код и повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03472
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03479
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03501
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03538
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-05402
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-05407
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-11-14
BDU:2024-05430
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-14
BDU:2024-05431
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-11-14
BDU:2024-05433
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-18
BDU:2024-05437
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-03-13
CVE-2024-21103
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21106
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).
Modified: 2025-05-08
CVE-2024-21107
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 6.7 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21108
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 3.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
Modified: 2024-12-05
CVE-2024-21109
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).
Modified: 2025-05-08
CVE-2024-21110
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H).
Modified: 2025-05-09
CVE-2024-21111
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-28
CVE-2024-21112
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-18
CVE-2024-21113
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-05-08
CVE-2024-21114
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-25
CVE-2024-21115
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-06-09
CVE-2024-21116
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-27
CVE-2024-21121
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N).
Package kernel-modules-virtualbox-un-def updated to version 7.0.18-alt1.394782.1 for branch sisyphus in task 347433.
Closed vulnerabilities
Modified: 2024-11-14
BDU:2024-03172
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03229
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии или выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03425
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код и повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03472
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03479
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03501
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03538
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-05402
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-05407
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-11-14
BDU:2024-05430
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-14
BDU:2024-05431
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-11-14
BDU:2024-05433
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-18
BDU:2024-05437
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-03-13
CVE-2024-21103
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21106
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).
Modified: 2025-05-08
CVE-2024-21107
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 6.7 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21108
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 3.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
Modified: 2024-12-05
CVE-2024-21109
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).
Modified: 2025-05-08
CVE-2024-21110
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H).
Modified: 2025-05-09
CVE-2024-21111
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-28
CVE-2024-21112
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-18
CVE-2024-21113
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-05-08
CVE-2024-21114
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-25
CVE-2024-21115
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-06-09
CVE-2024-21116
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-27
CVE-2024-21121
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N).
Package kernel-modules-virtualbox-std-def updated to version 7.0.18-alt1.393562.1 for branch sisyphus in task 347433.
Closed vulnerabilities
Modified: 2024-11-14
BDU:2024-03172
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03229
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии или выполнить произвольный код
Modified: 2024-11-14
BDU:2024-03425
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код и повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03472
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03479
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03501
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-03538
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-14
BDU:2024-05402
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-14
BDU:2024-05407
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-11-14
BDU:2024-05430
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-14
BDU:2024-05431
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-11-14
BDU:2024-05433
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-18
BDU:2024-05437
Уязвимость компонента Core программного средства виртуализации Oracle VM VirtualBox, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-03-13
CVE-2024-21103
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21106
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).
Modified: 2025-05-08
CVE-2024-21107
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 6.7 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H).
Modified: 2024-12-05
CVE-2024-21108
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 3.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
Modified: 2024-12-05
CVE-2024-21109
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).
Modified: 2025-05-08
CVE-2024-21110
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H).
Modified: 2025-05-09
CVE-2024-21111
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Windows hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-28
CVE-2024-21112
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-18
CVE-2024-21113
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-05-08
CVE-2024-21114
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-03-25
CVE-2024-21115
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Modified: 2025-06-09
CVE-2024-21116
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: This vulnerability applies to Linux hosts only. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
Modified: 2025-03-27
CVE-2024-21121
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.16. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N).
Closed vulnerabilities
Modified: 2025-09-23
BDU:2024-03786
Уязвимость браузеров Mozilla Firefox, Firefox ESR и почтового клиента Thunderbird, связанная с использованием памяти после ее освобождения, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-03795
Уязвимость реализации протокола HTTP/2 браузеров Mozilla Firefox, Firefox ESR и почтового клиента Thunderbird, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-07-24
BDU:2024-03873
Уязвимость компонента Garbage Collector («Сборщик мусора») браузеров Mozilla Firefox, Firefox ESR и почтового клиента Thunderbird, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-26
BDU:2024-03908
Уязвимость браузеров Mozilla Firefox, Firefox ESR и почтового клиента Thunderbird операционных систем Windows, связанная с отсутствием предупреждения об опасных действиях, позволяющая нарушителю обойти ограничения безопасности и выполнить произвольный код
Modified: 2025-09-23
BDU:2024-03909
Уязвимость браузеров Mozilla Firefox, Firefox ESR и почтового клиента Thunderbird, связанная с выходом операции за границы буфера в памяти, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-04-01
CVE-2024-3302
There was no limit to the number of HTTP/2 CONTINUATION frames that would be processed. A server could abuse this to create an Out of Memory condition in the browser. This vulnerability affects Firefox < 125, Firefox ESR < 115.10, and Thunderbird < 115.10.
- https://bugzilla.mozilla.org/show_bug.cgi?id=1881183
- https://kb.cert.org/vuls/id/421644
- https://lists.debian.org/debian-lts-announce/2024/04/msg00012.html
- https://lists.debian.org/debian-lts-announce/2024/04/msg00013.html
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
- https://bugzilla.mozilla.org/show_bug.cgi?id=1881183
- https://kb.cert.org/vuls/id/421644
- https://lists.debian.org/debian-lts-announce/2024/04/msg00012.html
- https://lists.debian.org/debian-lts-announce/2024/04/msg00013.html
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
Modified: 2025-04-01
CVE-2024-3857
The JIT created incorrect code for arguments in certain cases. This led to potential use-after-free crashes during garbage collection. This vulnerability affects Firefox < 125, Firefox ESR < 115.10, and Thunderbird < 115.10.
- https://bugzilla.mozilla.org/show_bug.cgi?id=1886683
- https://lists.debian.org/debian-lts-announce/2024/04/msg00012.html
- https://lists.debian.org/debian-lts-announce/2024/04/msg00013.html
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
- https://bugzilla.mozilla.org/show_bug.cgi?id=1886683
- https://lists.debian.org/debian-lts-announce/2024/04/msg00012.html
- https://lists.debian.org/debian-lts-announce/2024/04/msg00013.html
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
Modified: 2025-04-01
CVE-2024-3859
On 32-bit versions there were integer-overflows that led to an out-of-bounds-read that potentially could be triggered by a malformed OpenType font. This vulnerability affects Firefox < 125, Firefox ESR < 115.10, and Thunderbird < 115.10.
- https://bugzilla.mozilla.org/show_bug.cgi?id=1874489
- https://lists.debian.org/debian-lts-announce/2024/04/msg00012.html
- https://lists.debian.org/debian-lts-announce/2024/04/msg00013.html
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
- https://bugzilla.mozilla.org/show_bug.cgi?id=1874489
- https://lists.debian.org/debian-lts-announce/2024/04/msg00012.html
- https://lists.debian.org/debian-lts-announce/2024/04/msg00013.html
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
Modified: 2025-04-01
CVE-2024-3861
If an AlignedBuffer were assigned to itself, the subsequent self-move could result in an incorrect reference count and later use-after-free. This vulnerability affects Firefox < 125, Firefox ESR < 115.10, and Thunderbird < 115.10.
- https://bugzilla.mozilla.org/show_bug.cgi?id=1883158
- https://lists.debian.org/debian-lts-announce/2024/04/msg00012.html
- https://lists.debian.org/debian-lts-announce/2024/04/msg00013.html
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
- https://bugzilla.mozilla.org/show_bug.cgi?id=1883158
- https://lists.debian.org/debian-lts-announce/2024/04/msg00012.html
- https://lists.debian.org/debian-lts-announce/2024/04/msg00013.html
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
Modified: 2025-03-28
CVE-2024-3863
The executable file warning was not presented when downloading .xrm-ms files. *Note: This issue only affected Windows operating systems. Other operating systems are unaffected.* This vulnerability affects Firefox < 125, Firefox ESR < 115.10, and Thunderbird < 115.10.
- https://bugzilla.mozilla.org/show_bug.cgi?id=1885855
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
- https://bugzilla.mozilla.org/show_bug.cgi?id=1885855
- https://www.mozilla.org/security/advisories/mfsa2024-18/
- https://www.mozilla.org/security/advisories/mfsa2024-19/
- https://www.mozilla.org/security/advisories/mfsa2024-20/
