CRITICAL9.0
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xКРИТИЧЕСКАЯ 9.0
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:HCVSS 2.0ВЫСОКАЯ 7.6
CVSS:2.0/AV:N/AC:H/Au:N/C:C/I:C/A:C
ALT-PU-2023-8872-15Обновление пакета kernel-image-un-def в ветке sisyphus
Серьёзность:
Закрытые проблемы (45)
HIGH8.1
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xВЫСОКАЯ 8.1
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0ВЫСОКАЯ 7.6
CVSS:2.0/AV:N/AC:H/Au:N/C:C/I:C/A:CHIGH7.5
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0ВЫСОКАЯ 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CHIGH8.1
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
CVSS 3.xВЫСОКАЯ 8.1
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0ВЫСОКАЯ 7.6
CVSS:2.0/AV:N/AC:H/Au:N/C:C/I:C/A:CHIGH7.5
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0ВЫСОКАЯ 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CMEDIUM5.5
Уязвимость функции dev_get_drvdata() драйвера контроллера Cadence Quad SPI (drivers/spi/spi-cadence-quadspi.c)i ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
HIGH7.8
Уязвимость функции gfx_v9_0_hw_fini() модуля drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.0
Уязвимость функции rxrpc_wait_to_be_connected() модуля net/rxrpc/sendmsg.c поддержки сокетов сеанса RxRPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость функции get_max_inline_xattr_value_size() в модуле fs/ext4/inline.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
HIGH7.8
Уязвимость функции dx_probe() модуля fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
MEDIUM5.5
Уязвимость функции ext4_validate_block_bitmap() модуля fs/ext4/balloc.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции init_amd() модуля arch/x86/lib/clear_page_64.S ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции gmc_v11_0_hw_fini() модуля drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CMEDIUM5.5
Уязвимость функции ntfs_lookup() модуля fs/ntfs3/namei.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
HIGH7.0
Уязвимость функции skb_copy_ubufs() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:CHIGH7.0
Уязвимость функции otx2_remove() модуля drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c драйвера сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xВЫСОКАЯ 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:CСсылки
MEDIUM5.5
Уязвимость функции ext4_mb_release_group_pa() модуля fs/ext4/mballoc.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции amdgpu_cs_submit() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции ext4_writepages() модуля fs/ext4/ext4.h файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
HIGH7.8
Уязвимость функции sendmsg() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CСсылки
MEDIUM5.5
Уязвимость функции amdgpu_irq_put() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
MEDIUM5.5
Уязвимость функции ionic_devlink_alloc() в модуле drivers/net/ethernet/pensando/ionic/ionic_devlink.c драйвера сетевых адаптеров Ethernet Pensando ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CСсылки
HIGH7.5
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_SESSION_SETUP commands. The issue results from the lack of control of resource consumption. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://access.redhat.com/security/cve/CVE-2023-32247
- https://bugzilla.redhat.com/show_bug.cgi?id=2219803
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20478/
- https://access.redhat.com/security/cve/CVE-2023-32247
- https://bugzilla.redhat.com/show_bug.cgi?id=2219803
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20478/
HIGH8.1
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.
CVSS 3.xВЫСОКАЯ 8.1
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://access.redhat.com/security/cve/CVE-2023-32250
- https://bugzilla.redhat.com/show_bug.cgi?id=2208849
- https://security.netapp.com/advisory/ntap-20230824-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-698/
- https://access.redhat.com/security/cve/CVE-2023-32250
- https://bugzilla.redhat.com/show_bug.cgi?id=2208849
- https://security.netapp.com/advisory/ntap-20230824-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-698/
HIGH7.5
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_LOGOFF commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- https://access.redhat.com/security/cve/CVE-2023-32252
- https://bugzilla.redhat.com/show_bug.cgi?id=2219815
- https://security.netapp.com/advisory/ntap-20231124-0001/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20590/
- https://access.redhat.com/security/cve/CVE-2023-32252
- https://bugzilla.redhat.com/show_bug.cgi?id=2219815
- https://security.netapp.com/advisory/ntap-20231124-0001/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20590/
HIGH8.1
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP and SMB2_LOGOFF commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.
CVSS 3.xВЫСОКАЯ 8.1
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://access.redhat.com/security/cve/CVE-2023-32257
- https://bugzilla.redhat.com/show_bug.cgi?id=2219806
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20596/
- https://access.redhat.com/security/cve/CVE-2023-32257
- https://bugzilla.redhat.com/show_bug.cgi?id=2219806
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20596/
HIGH8.1
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_LOGOFF and SMB2_CLOSE commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.
CVSS 3.xВЫСОКАЯ 8.1
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://access.redhat.com/security/cve/CVE-2023-32258
- https://bugzilla.redhat.com/show_bug.cgi?id=2219809
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20796/
- https://access.redhat.com/security/cve/CVE-2023-32258
- https://bugzilla.redhat.com/show_bug.cgi?id=2219809
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20796/
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid deadlock in fs reclaim with page writeback Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0 CPU1 ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini
The gmc.ecc_irq is enabled by firmware per IFWI setting,
and the host driver is not privileged to enable/disable
the interrupt. So, it is meaningless to use the amdgpu_irq_put
function in gmc_v10_0_hw_fini, which also leads to the call
trace.
[ 82.340264] Call Trace:
[ 82.340265]
[ 82.340269] gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu]
[ 82.340447] gmc_v10_0_suspend+0xe/0x20 [amdgpu]
[ 82.340623] amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu]
[ 82.340789] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]
[ 82.340955] amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu]
[ 82.341122] amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu]
[ 82.341359] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]
[ 82.341529] process_one_work+0x21d/0x3f0
[ 82.341535] worker_thread+0x1fa/0x3c0
[ 82.341538] ? process_one_work+0x3f0/0x3f0
[ 82.341540] kthread+0xff/0x130
[ 82.341544] ? kthread_complete_and_exit+0x20/0x20
[ 82.341547] ret_from_fork+0x22/0x30
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Make it so that a waiting process can be aborted When sendmsg() creates an rxrpc call, it queues it to wait for a connection and channel to be assigned and then waits before it can start shovelling data as the encrypted DATA packet content includes a summary of the connection parameters. However, sendmsg() may get interrupted before a connection gets assigned and further sendmsg() calls will fail with EBUSY until an assignment is made. Fix this so that the call can at least be aborted without failing on EBUSY. We have to be careful here as sendmsg() mustn't be allowed to start the call timer if the call doesn't yet have a connection assigned as an oops may follow shortly thereafter.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: drop redundant sched job cleanup when cs is aborted Once command submission failed due to userptr invalidation in amdgpu_cs_submit, legacy code will perform cleanup of scheduler job. However, it's not needed at all, as former commit has integrated job cleanup stuff into amdgpu_job_free. Otherwise, because of double free, a NULL pointer dereference will occur in such scenario. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini
The gmc.ecc_irq is enabled by firmware per IFWI setting,
and the host driver is not privileged to enable/disable
the interrupt. So, it is meaningless to use the amdgpu_irq_put
function in gmc_v11_0_hw_fini, which also leads to the call
trace.
[ 102.980303] Call Trace:
[ 102.980303]
[ 102.980304] gmc_v11_0_hw_fini+0x54/0x90 [amdgpu]
[ 102.980357] gmc_v11_0_suspend+0xe/0x20 [amdgpu]
[ 102.980409] amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu]
[ 102.980459] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]
[ 102.980520] amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu]
[ 102.980573] amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu]
[ 102.980687] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]
[ 102.980740] process_one_work+0x21f/0x3f0
[ 102.980741] worker_thread+0x200/0x3e0
[ 102.980742] ? process_one_work+0x3f0/0x3f0
[ 102.980743] kthread+0xfd/0x130
[ 102.980743] ? kthread_complete_and_exit+0x20/0x20
[ 102.980744] ret_from_fork+0x22/0x30
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ext4: add bounds checking in get_max_inline_xattr_value_size() Normally the extended attributes in the inode body would have been checked when the inode is first opened, but if someone is writing to the block device while the file system is mounted, it's possible for the inode table to get corrupted. Add bounds checking to avoid reading beyond the end of allocated memory if this happens.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/1d2caddbeeee56fbbc36b428c5b909c3ad88eb7f
- https://git.kernel.org/stable/c/2220eaf90992c11d888fe771055d4de330385f01
- https://git.kernel.org/stable/c/3d7b8fbcd2273e2b9f4c6de5ce2f4c0cd3cb1205
- https://git.kernel.org/stable/c/4597554b4f7b29e7fd78aa449bab648f8da4ee2c
- https://git.kernel.org/stable/c/486efbbc9445dca7890a1b86adbccb88b91284b0
- https://git.kernel.org/stable/c/5a229d21b98d132673096710e8281ef522dab1d1
- https://git.kernel.org/stable/c/88a06a94942c5c0a896e9da1113a6bb29e36cbef
- https://git.kernel.org/stable/c/e780058bd75614b66882bc02620ddbd884171560
- https://git.kernel.org/stable/c/f22b274429e88d3dc7e79d375b56ce4f2f59f0b4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix null-ptr-deref on inode->i_op in ntfs_lookup()
Syzbot reported a null-ptr-deref bug:
ntfs3: loop0: Different NTFS' sector size (1024) and media sector size
(512)
ntfs3: loop0: Mark volume as dirty due to NTFS errors
general protection fault, probably for non-canonical address
0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:d_flags_for_inode fs/dcache.c:1980 [inline]
RIP: 0010:__d_add+0x5ce/0x800 fs/dcache.c:2796
Call Trace:
d_splice_alias+0x122/0x3b0 fs/dcache.c:3191
lookup_open fs/namei.c:3391 [inline]
open_last_lookups fs/namei.c:3481 [inline]
path_openat+0x10e6/0x2df0 fs/namei.c:3688
do_filp_open+0x264/0x4f0 fs/namei.c:3718
do_sys_openat2+0x124/0x4e0 fs/open.c:1310
do_sys_open fs/open.c:1326 [inline]
__do_sys_open fs/open.c:1334 [inline]
__se_sys_open fs/open.c:1330 [inline]
__x64_sys_open+0x221/0x270 fs/open.c:1330
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
If the MFT record of ntfs inode is not a base record, inode->i_op can be
NULL. And a null-ptr-deref may happen:
ntfs_lookup()
dir_search_u() # inode->i_op is set to NULL
d_splice_alias()
__d_add()
d_flags_for_inode() # inode->i_op->get_link null-ptr-deref
Fix this by adding a Check on inode->i_op before calling the
d_splice_alias() function.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/254e69f284d7270e0abdc023ee53b71401c3ba0c
- https://git.kernel.org/stable/c/2ba22cbc6a1cf4b58195adbee0b80262e53992d3
- https://git.kernel.org/stable/c/d69d5e2a81df94534bdb468bcdd26060fcb7191a
- https://git.kernel.org/stable/c/e78240bc4b94fc42854d65e657bb998100cc8e1b
- https://git.kernel.org/stable/c/f8d9e062a695a3665c4635c4f216a75912687598
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in mb_find_extent
Syzbot found the following issue:
EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!
EXT4-fs (loop0): orphan cleanup on readonly fs
------------[ cut here ]------------
WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30
Modules linked in:
CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869
RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293
RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0
RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040
RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402
R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000
R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc
FS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307
ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735
ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605
ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286
ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651
ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864
ext4_bread+0x2a/0x170 fs/ext4/inode.c:920
ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105
write_blk fs/quota/quota_tree.c:64 [inline]
get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130
do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340
do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
dq_insert_tree fs/quota/quota_tree.c:401 [inline]
qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420
v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358
dquot_acquire+0x348/0x670 fs/quota/dquot.c:444
ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740
dqget+0x999/0xdc0 fs/quota/dquot.c:914
__dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492
ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329
ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474
__ext4_fill_super fs/ext4/super.c:5516 [inline]
ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644
get_tree_bdev+0x400/0x620 fs/super.c:1282
vfs_get_tree+0x88/0x270 fs/super.c:1489
do_new_mount+0x289/0xad0 fs/namespace.c:3145
do_mount fs/namespace.c:3488 [inline]
__do_sys_mount fs/namespace.c:3697 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Add some debug information:
mb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/1@3735929054 64 64 7
block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Acctually, blocks per group is 64, but block bitmap indicate at least has
128 blocks. Now, ext4_validate_block_bitmap() didn't check invalid block's
bitmap if set.
To resolve above issue, add check like fsck "Padding at end of block bitmap is
not set".
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/1b90fbc7590124c57a2e590de7fd07eba26606f1
- https://git.kernel.org/stable/c/5d356d902e9d5b1aaaaf2326d365340fa8a90c1b
- https://git.kernel.org/stable/c/775b00ba23f6f916fe2ac60c5ff7fd0fe4f28d0d
- https://git.kernel.org/stable/c/d55e76e11592a1d18a179c7fd34ca1b52632beb3
- https://git.kernel.org/stable/c/dba62fa84a8eac44a53a2862de8a40e5bdfa0ae3
- https://git.kernel.org/stable/c/dd45e536f47a82e0a405f9a4b6c7ceb367171ee9
- https://git.kernel.org/stable/c/e4d503c956a744cb59e509ca5f134cfad423c7a3
- https://git.kernel.org/stable/c/fa08a7b61dff8a4df11ff1e84abfc214b487caf7
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix potential data race in rxrpc_wait_to_be_connected() Inside the loop in rxrpc_wait_to_be_connected() it checks call->error to see if it should exit the loop without first checking the call state. This is probably safe as if call->error is set, the call is dead anyway, but we should probably wait for the call state to have been set to completion first, lest it cause surprise on the way out. Fix this by only accessing call->error if the call is complete. We don't actually need to access the error inside the loop as we'll do that after. This caused the following report: BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1: rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22 rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479 rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714 rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline] rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350 rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464 rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461 kthread+0x1ac/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0: rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296 rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726 rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501 ___sys_sendmsg net/socket.c:2555 [inline] __sys_sendmmsg+0x263/0x500 net/socket.c:2641 __do_sys_sendmmsg net/socket.c:2670 [inline] __se_sys_sendmmsg net/socket.c:2667 [inline] __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x00000000 -> 0xffffffea
CVSS 3.xСРЕДНЯЯ 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ext4: remove a BUG_ON in ext4_mb_release_group_pa() If a malicious fuzzer overwrites the ext4 superblock while it is mounted such that the s_first_data_block is set to a very large number, the calculation of the block group can underflow, and trigger a BUG_ON check. Change this to be an ext4_warning so that we don't crash the kernel.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/185062a21976fbc38f2efd296951b02c4500cf65
- https://git.kernel.org/stable/c/463808f237cf73e98a1a45ff7460c2406a150a0b
- https://git.kernel.org/stable/c/53c14e7cc2257191ba15425c15638fc4f8abb92b
- https://git.kernel.org/stable/c/978e5e9111af18741449b81fefd531a622dd969a
- https://git.kernel.org/stable/c/b0fc279de4bf17e1710bb7e83906538ff8f11111
- https://git.kernel.org/stable/c/bf2a16eb4e6d06124bd8436d4546f61539a65f29
- https://git.kernel.org/stable/c/d5bf8f7fb3ee3d99d1303ceb54599ea0599a4a5b
- https://git.kernel.org/stable/c/d87a4e4094c9879fc8acdff8ce59fdffa979c8e0
- https://git.kernel.org/stable/c/ef16d8a1798db1a1604ac44ca1bd73ec6bebf483
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ionic: catch failure from devlink_alloc Add a check for NULL on the alloc return. If devlink_alloc() fails and we try to use devlink_priv() on the NULL return, the kernel gets very unhappy and panics. With this fix, the driver load will still fail, but at least it won't panic the kernel.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/0020c16c8af7f4bc9503a2088fb30793b6771fac
- https://git.kernel.org/stable/c/0d02efe7f25158c93146e3bb827bc7bb3cd5e71a
- https://git.kernel.org/stable/c/4a54903ff68ddb33b6463c94b4eb37fc584ef760
- https://git.kernel.org/stable/c/5325f50de5b1433b27dda7ccff5cb7283722a3f1
- https://git.kernel.org/stable/c/c177dd465f5c1e5f242cdb9258826c591c257e9a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras
gfx9 cp_ecc_error_irq is only enabled when legacy gfx ras is assert.
So in gfx_v9_0_hw_fini, interrupt disablement for cp_ecc_error_irq
should be executed under such condition, otherwise, an amdgpu_irq_put
calltrace will occur.
[ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
[ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246
[ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX: 0000000000000000
[ 7283.170969] RDX: 0000000000000000 RSI: ffff98d89da2bef8 RDI: ffff98d89da20000
[ 7283.170971] RBP: ffff98d89da20000 R08: ffff98d89da2ca18 R09: 0000000000000006
[ 7283.170973] R10: ffffd5764243c008 R11: 0000000000000000 R12: 0000000000001050
[ 7283.170975] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
[ 7283.170978] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000
[ 7283.170981] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0
[ 7283.170986] Call Trace:
[ 7283.170988]
[ 7283.170989] gfx_v9_0_hw_fini+0x1c/0x6d0 [amdgpu]
[ 7283.171655] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]
[ 7283.172245] amdgpu_device_suspend+0x103/0x180 [amdgpu]
[ 7283.172823] amdgpu_pmops_freeze+0x21/0x60 [amdgpu]
[ 7283.173412] pci_pm_freeze+0x54/0xc0
[ 7283.173419] ? __pfx_pci_pm_freeze+0x10/0x10
[ 7283.173425] dpm_run_callback+0x98/0x200
[ 7283.173430] __device_suspend+0x164/0x5f0
v2: drop gfx11 as it's fixed in a different solution by retiring cp_ecc_irq funcs(Hawking)
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/20ca90ceda71ed90a4d6960acbe7d5e120b40c0d
- https://git.kernel.org/stable/c/3d28af21a874c5123d1681c2d686627f7ff7e488
- https://git.kernel.org/stable/c/4a76680311330aefe5074bed8f06afa354b85c48
- https://git.kernel.org/stable/c/625d4112ea25dbad7ddf749fd5c1287ceffb2339
- https://git.kernel.org/stable/c/cd3c0f7013c37cd24fc40b601319007f136c1201
- https://git.kernel.org/stable/c/efce310db74fdc6d2acd959f3582972ae4a8d7d5
- https://git.kernel.org/stable/c/f661ad53658a1ea35c004af1f5fbe25c4d1cdb08
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ext4: improve error handling from ext4_dirhash() The ext4_dirhash() will *almost* never fail, especially when the hash tree feature was first introduced. However, with the addition of support of encrypted, casefolded file names, that function can most certainly fail today. So make sure the callers of ext4_dirhash() properly check for failures, and reflect the errors back up to their callers.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/4b3cb1d108bfc2aebb0d7c8a52261a53cf7f5786
- https://git.kernel.org/stable/c/70d579aefa652a06af97e013e3fbbabbe5a43553
- https://git.kernel.org/stable/c/b2531936118deb3f479c4fa1bcd787b74b8faa6a
- https://git.kernel.org/stable/c/c1fae027da61fe8e7eb99f7244297e81bc0f1e43
- https://git.kernel.org/stable/c/f68876aeef96ef8b708ab10b9cb47ce0a5adb424
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm: fix vram leak on bind errors Make sure to release the VRAM buffer also in a case a subcomponent fails to bind. Patchwork: https://patchwork.freedesktop.org/patch/525094/
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: mcs: Fix NULL pointer dereferences When system is rebooted after creating macsec interface below NULL pointer dereference crashes occurred. This patch fixes those crashes by using correct order of teardown [ 3324.406942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 3324.415726] Mem abort info: [ 3324.418510] ESR = 0x96000006 [ 3324.421557] EC = 0x25: DABT (current EL), IL = 32 bits [ 3324.426865] SET = 0, FnV = 0 [ 3324.429913] EA = 0, S1PTW = 0 [ 3324.433047] Data abort info: [ 3324.435921] ISV = 0, ISS = 0x00000006 [ 3324.439748] CM = 0, WnR = 0 .... [ 3324.575915] Call trace: [ 3324.578353] cn10k_mdo_del_secy+0x24/0x180 [ 3324.582440] macsec_common_dellink+0xec/0x120 [ 3324.586788] macsec_notify+0x17c/0x1c0 [ 3324.590529] raw_notifier_call_chain+0x50/0x70 [ 3324.594965] call_netdevice_notifiers_info+0x34/0x7c [ 3324.599921] rollback_registered_many+0x354/0x5bc [ 3324.604616] unregister_netdevice_queue+0x88/0x10c [ 3324.609399] unregister_netdev+0x20/0x30 [ 3324.613313] otx2_remove+0x8c/0x310 [ 3324.616794] pci_device_shutdown+0x30/0x70 [ 3324.620882] device_shutdown+0x11c/0x204 [ 966.664930] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 966.673712] Mem abort info: [ 966.676497] ESR = 0x96000006 [ 966.679543] EC = 0x25: DABT (current EL), IL = 32 bits [ 966.684848] SET = 0, FnV = 0 [ 966.687895] EA = 0, S1PTW = 0 [ 966.691028] Data abort info: [ 966.693900] ISV = 0, ISS = 0x00000006 [ 966.697729] CM = 0, WnR = 0 [ 966.833467] Call trace: [ 966.835904] cn10k_mdo_stop+0x20/0xa0 [ 966.839557] macsec_dev_stop+0xe8/0x11c [ 966.843384] __dev_close_many+0xbc/0x140 [ 966.847298] dev_close_many+0x84/0x120 [ 966.851039] rollback_registered_many+0x114/0x5bc [ 966.855735] unregister_netdevice_many.part.0+0x14/0xa0 [ 966.860952] unregister_netdevice_many+0x18/0x24 [ 966.865560] macsec_notify+0x1ac/0x1c0 [ 966.869303] raw_notifier_call_chain+0x50/0x70 [ 966.873738] call_netdevice_notifiers_info+0x34/0x7c [ 966.878694] rollback_registered_many+0x354/0x5bc [ 966.883390] unregister_netdevice_queue+0x88/0x10c [ 966.888173] unregister_netdev+0x20/0x30 [ 966.892090] otx2_remove+0x8c/0x310 [ 966.895571] pci_device_shutdown+0x30/0x70 [ 966.899660] device_shutdown+0x11c/0x204 [ 966.903574] __do_sys_reboot+0x208/0x290 [ 966.907487] __arm64_sys_reboot+0x20/0x30 [ 966.911489] el0_svc_handler+0x80/0x1c0 [ 966.915316] el0_svc+0x8/0x180 [ 966.918362] Code: f9400000 f9400a64 91220014 f94b3403 (f9400060) [ 966.924448] ---[ end trace 341778e799c3d8d7 ]---
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: x86: fix clear_user_rep_good() exception handling annotation This code no longer exists in mainline, because it was removed in commit d2c95f9d6802 ("x86: don't use REP_GOOD or ERMS for user memory clearing") upstream. However, rather than backport the full range of x86 memory clearing and copying cleanups, fix the exception table annotation placement for the final 'rep movsb' in clear_user_rep_good(): rather than pointing at the actual instruction that did the user space access, it pointed to the register move just before it. That made sense from a code flow standpoint, but not from an actual usage standpoint: it means that if user access takes an exception, the exception handler won't actually find the instruction in the exception tables. As a result, rather than fixing it up and returning -EFAULT, it would then turn it into a kernel oops report instead, something like: BUG: unable to handle page fault for address: 0000000020081000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page ... RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147 ... Call Trace: __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline] clear_user arch/x86/include/asm/uaccess_64.h:124 [inline] iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800 iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline] iomap_dio_iter fs/iomap/direct-io.c:440 [inline] __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601 iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689 ext4_dio_read_iter fs/ext4/file.c:94 [inline] ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145 call_read_iter include/linux/fs.h:2183 [inline] do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733 do_iter_read+0x2f2/0x750 fs/read_write.c:796 vfs_readv+0xe5/0x150 fs/read_write.c:916 do_preadv+0x1b6/0x270 fs/read_write.c:1008 __do_sys_preadv2 fs/read_write.c:1070 [inline] __se_sys_preadv2 fs/read_write.c:1061 [inline] __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd which then looks like a filesystem bug rather than the incorrect exception annotation that it is. [ The alternative to this one-liner fix is to take the upstream series that cleans this all up: 68674f94ffc9 ("x86: don't use REP_GOOD or ERMS for small memory copies") 20f3337d350c ("x86: don't use REP_GOOD or ERMS for small memory clearing") adfcf4231b8c ("x86: don't use REP_GOOD or ERMS for user memory copies") * d2c95f9d6802 ("x86: don't use REP_GOOD or ERMS for user memory clearing") 3639a535587d ("x86: move stac/clac from user copy routines into callers") 577e6a7fd50d ("x86: inline the 'rep movs' in user copies for the FSRM case") 8c9b6a88b7e2 ("x86: improve on the non-rep 'clear_user' function") 427fda2c8a49 ("x86: improve on the non-rep 'copy_user' function") * e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM") e1f2750edc4a ("x86: remove 'zerorest' argument from __copy_user_nocache()") 034ff37d3407 ("x86: rewrite '__copy_user_nocache' function") with either the whole series or at a minimum the two marked commits being needed to fix this issue ]
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tcp: fix skb_copy_ubufs() vs BIG TCP David Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy using hugepages, and skb length bigger than ~68 KB. skb_copy_ubufs() assumed it could copy all payload using up to MAX_SKB_FRAGS order-0 pages. This assumption broke when BIG TCP was able to put up to 512 KB per skb. We did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45 and limit gso_max_size to 180000. A solution is to use higher order pages if needed. v2: add missing __GFP_COMP, or we leak memory.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Both cadence-quadspi ->runtime_suspend() and ->runtime_resume() implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev); This obviously cannot be correct, unless "struct cqspi_st" is the first member of " struct spi_controller", or the other way around, but it is not the case. "struct spi_controller" is allocated by devm_spi_alloc_host(), which allocates an extra amount of memory for private data, used to store "struct cqspi_st". The ->probe() function of the cadence-quadspi driver then sets the device drvdata to store the address of the "struct cqspi_st" structure. Therefore: struct cqspi_st *cqspi = dev_get_drvdata(dev); is correct, but: struct spi_controller *host = dev_get_drvdata(dev); is not, as it makes "host" point not to a "struct spi_controller" but to the same "struct cqspi_st" structure as above. This obviously leads to bad things (memory corruption, kernel crashes) directly during ->probe(), as ->probe() enables the device using PM runtime, leading the ->runtime_resume() hook being called, which in turns calls spi_controller_resume() with the wrong pointer. This has at least been reported [0] to cause a kernel crash, but the exact behavior will depend on the memory contents. [0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/ This issue potentially affects all platforms that are currently using the cadence-quadspi driver.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/03f1573c9587029730ca68503f5062105b122f61
- https://git.kernel.org/stable/c/2c914aac9522f6e93822c18dff233d3e92399c81
- https://git.kernel.org/stable/c/32ce3bb57b6b402de2aec1012511e7ac4e7449dc
- https://git.kernel.org/stable/c/34e1d5c4407c78de0e3473e1fbf8fb74dbe66d03
- https://git.kernel.org/stable/c/03f1573c9587029730ca68503f5062105b122f61
- https://git.kernel.org/stable/c/32ce3bb57b6b402de2aec1012511e7ac4e7449dc
- https://git.kernel.org/stable/c/34e1d5c4407c78de0e3473e1fbf8fb74dbe66d03
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html