CVSS: 7.0EPSS: 0%CPEs: 6EXPL: 0CVE-2024-34027 – f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
https://notcve.org/view.php?id=CVE-2024-34027
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. • https://git.kernel.org/stable/c/c75488fb4d82b697f381f855bf5b16779df440aa https://git.kernel.org/stable/c/a6e1f7744e9b84f86a629a76024bba8468aa153b https://git.kernel.org/stable/c/b5bac43875aa27ec032dbbb86173baae6dce6182 https://git.kernel.org/stable/c/5d47d63883735718825ca2efc4fca6915469774f https://git.kernel.org/stable/c/329edb7c9e3b6ca27e6ca67ab1cdda1740fb3a2b https://git.kernel.org/stable/c/69136304fd144144a4828c7b7b149d0f80321ba4 https://git.kernel.org/stable/c/0a4ed2d97cb6d044196cc3e726b6699222b41019 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-33847 – f2fs: compress: don't allow unaligned truncation on released compress inode
https://notcve.org/view.php?id=CVE-2024-33847
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: don't allow unaligned truncation on released compress inode f2fs image may be corrupted after below testcase: - mkfs.f2fs -O extra_attr,compression -f /dev/vdb - mount /dev/vdb /mnt/f2fs - touch /mnt/f2fs/file - f2fs_io setflags compression /mnt/f2fs/file - dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=4 - f2fs_io release_cblocks /mnt/f2fs/file - truncate -s 8192 /mnt/f2fs/file - umount /mnt/f2fs - fsck.f2fs /dev/vdb [ASSERT] (fsck_chk_inode_blk:1256) --> ino: 0x5 has i_blocks: 0x00000002, but has 0x3 blocks [FSCK] valid_block_count matching with CP [Fail] [0x4, 0x5] [FSCK] other corrupted bugs [Fail] The reason is: partial truncation assume compressed inode has reserved blocks, after partial truncation, valid block count may change w/o .i_blocks and .total_valid_block_count update, result in corruption. This patch only allow cluster size aligned truncation on released compress inode for fixing. • https://git.kernel.org/stable/c/c61404153eb683da9c35aad133131554861ed561 https://git.kernel.org/stable/c/8acae047215024d1ac499b3c8337ef1b952f160b https://git.kernel.org/stable/c/3ccf5210dc941a7aa0180596ac021568be4d35ec https://git.kernel.org/stable/c/9f9341064a9b5246a32a7fe56b9f80c6f7f3c62d https://git.kernel.org/stable/c/5268241b41b1c5d0acca75e9b97d4fd719251c8c https://git.kernel.org/stable/c/29ed2b5dd521ce7c5d8466cd70bf0cc9d07afeee https://git.kernel.org/stable/c/b8962cf98595d1ec62f40f23667de830567ec8bc •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39292 – um: Add winch to winch_handlers before registering winch IRQ
https://notcve.org/view.php?id=CVE-2024-39292
In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: Agregar cabrestante a winch_handlers antes de registrar la IRQ del cabrestante Registrar una IRQ del cabrestante es picante, puede ocurrir una interrupción antes de que el cabrestante se agregue a la lista de winch_handlers. Si eso sucede, Register_winch_irq() agrega a esa lista un cabrestante que está programado para ser liberado (o que ya ha sido) liberado, causando pánico más adelante en winch_cleanup(). Evite la ejecución agregando el cabrestante a la lista winch_handlers antes de registrar la IRQ y retrocediendo si um_request_irq() falla. • https://git.kernel.org/stable/c/42a359e31a0e438b5b978a8f0fecdbd3c86bb033 https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33 https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0 https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14 https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2 https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4 https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0 https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a • CWE-415: Double Free •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39291 – drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode()
https://notcve.org/view.php?id=CVE-2024-39291
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode() The function gfx_v9_4_3_init_microcode in gfx_v9_4_3.c was generating about potential truncation of output when using the snprintf function. The issue was due to the size of the buffer 'ucode_prefix' being too small to accommodate the maximum possible length of the string being written into it. The string being written is "amdgpu/%s_mec.bin" or "amdgpu/%s_rlc.bin", where %s is replaced by the value of 'chip_name'. The length of this string without the %s is 16 characters. The warning message indicated that 'chip_name' could be up to 29 characters long, resulting in a total of 45 characters, which exceeds the buffer size of 30 characters. To resolve this issue, the size of the 'ucode_prefix' buffer has been reduced from 30 to 15. This ensures that the maximum possible length of the string being written into the buffer will not exceed its size, thus preventing potential buffer overflow and truncation issues. Fixes the below with gcc W=1: drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c: In function ‘gfx_v9_4_3_early_init’: drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~ ...... 439 | r = gfx_v9_4_3_init_rlc_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~ ...... 443 | r = gfx_v9_4_3_init_cp_compute_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrigió el tamaño del búfer en gfx_v9_4_3_init_ cp_compute_microcode() y rlc_microcode() La función gfx_v9_4_3_init_microcode en gfx_v9_4_3.c generaba un posible truncamiento de la salida al usar la función snprintf. El problema se debía a que el tamaño del búfer 'ucode_prefix' era demasiado pequeño para acomodar la longitud máxima posible de la cadena que se estaba escribiendo en él. • https://git.kernel.org/stable/c/86301129698be52f8398f92ea8564168f6bfcae1 https://git.kernel.org/stable/c/19bd9537b6bc1c882df25206c15917214d8e9460 https://git.kernel.org/stable/c/f1b6a016dfa45cedc080d36fa5d6f22237d80e8b https://git.kernel.org/stable/c/acce6479e30f73ab0872e93a75aed1fb791d04ec https://access.redhat.com/security/cve/CVE-2024-39291 https://bugzilla.redhat.com/show_bug.cgi?id=2294223 • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38667 – riscv: prevent pt_regs corruption for secondary idle threads
https://notcve.org/view.php?id=CVE-2024-38667
In the Linux kernel, the following vulnerability has been resolved: riscv: prevent pt_regs corruption for secondary idle threads Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted. Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context. • https://git.kernel.org/stable/c/2875fe0561569f82d0e63658ccf0d11ce7da8922 https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44 https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80 https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af • CWE-787: Out-of-bounds Write •