CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-39478 – crypto: starfive - Do not free stack buffer
https://notcve.org/view.php?id=CVE-2024-39478
In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Do not free stack buffer RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: starfive: no liberar el búfer de pila Los datos de texto RSA utilizan un búfer de longitud variable asignado en la pila de software. Llamar a kfree provoca un comportamiento indefinido en operaciones posteriores. • https://git.kernel.org/stable/c/5944de192663f272033501dcd322b008fca72006 https://git.kernel.org/stable/c/d7f01649f4eaf1878472d3d3f480ae1e50d98f6c • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.5EPSS: 0%CPEs: 16EXPL: 0CVE-2024-39476 – md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
https://notcve.org/view.php?id=CVE-2024-39476
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid5: corrige el punto muerto que raid5d() espera a que se borre MD_SB_CHANGE_PENDING Xiao informó que la prueba lvm2 lvconvert-raid-takeover.sh puede bloquearse con una pequeña posibilidad, la causa principal es exactamente lo mismo que el commit bed9e27baf52 ("Revertir "md/raid5: Espere MD_SB_CHANGE_PENDING en raid5d") Sin embargo, Dan informó otro bloqueo después de eso, y Junxiao investigó el problema y descubrió que esto se debe a que la biografía conectada no puede emitir de raid5d(). La implementación actual en raid5d() tiene una dependencia extraña: 1) md_check_recovery() de raid5d() debe mantener 'reconfig_mutex' para borrar MD_SB_CHANGE_PENDING; 2) raid5d() maneja IO en un bucle muerto, hasta que se emiten todas las IO; 3) IO de raid5d() debe esperar a que se borre MD_SB_CHANGE_PENDING; Este comportamiento se introdujo antes de v2.6 y, como consecuencia, si otro contexto contiene 'reconfig_mutex' y md_check_recovery() no puede actualizar super_block, entonces raid5d() desperdiciará una CPU al 100% mediante el bucle muerto, hasta que 'reconfig_mutex' sea liberado. Consulte la implementación de raid1 y raid10, solucione este problema omitiendo el problema IO si MD_SB_CHANGE_PENDING todavía está configurado después de md_check_recovery(), el hilo del daemon se activará cuando se publique 'reconfig_mutex'. • https://git.kernel.org/stable/c/f3d55bd5b7b928ad82f8075d89c908702f3593ab https://git.kernel.org/stable/c/1c00bb624cd084e2006520ad0edacaff0fb941c4 https://git.kernel.org/stable/c/782b3e71c957991ac8ae53318bc369049d49bb53 https://git.kernel.org/stable/c/9e86dffd0b02594d2e7c60c6db9e889c0395414b https://git.kernel.org/stable/c/5e2cf333b7bd5d3e62595a44d598a254c697cd74 https://git.kernel.org/stable/c/7d808fe6af8409cf9f46ed2b10840e5788985e9b https://git.kernel.org/stable/c/1e8c1c2a92692881ac7ec92dcf1c8a846584251b https://git.kernel.org/stable/c/7f71d9817cea3582daa2e903596461f5f • CWE-667: Improper Locking CWE-833: Deadlock •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2024-39471 – drm/amdgpu: add error handle to avoid out-of-bounds
https://notcve.org/view.php?id=CVE-2024-39471
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add error handle to avoid out-of-bounds if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should be stop to avoid out-of-bounds read, so directly return -EINVAL. • https://git.kernel.org/stable/c/5594971e02764aa1c8210ffb838cb4e7897716e8 https://git.kernel.org/stable/c/8112fa72b7f139052843ff484130d6f97e9f052f https://git.kernel.org/stable/c/ea906e9ac61e3152bef63597f2d9f4a812fc346a https://git.kernel.org/stable/c/011552f29f20842c9a7a21bffe1f6a2d6457ba46 https://git.kernel.org/stable/c/5b0a3dc3e87821acb80e841b464d335aff242691 https://git.kernel.org/stable/c/0964c84b93db7fbf74f357c1e20957850e092db3 https://git.kernel.org/stable/c/8b2faf1a4f3b6c748c0da36cda865a226534d520 https://access.redhat.com/security/cve/CVE-2024-39471 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39469 – nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors
https://notcve.org/view.php?id=CVE-2024-39469
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors The error handling in nilfs_empty_dir() when a directory folio/page read fails is incorrect, as in the old ext2 implementation, and if the folio/page cannot be read or nilfs_check_folio() fails, it will falsely determine the directory as empty and corrupt the file system. In addition, since nilfs_empty_dir() does not immediately return on a failed folio/page read, but continues to loop, this can cause a long loop with I/O if i_size of the directory's inode is also corrupted, causing the log writer thread to wait and hang, as reported by syzbot. Fix these issues by making nilfs_empty_dir() immediately return a false value (0) if it fails to get a directory folio/page. • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/2ac8a2fe22bdde9eecce2a42cf5cab79333fb428 https://git.kernel.org/stable/c/405b71f1251e5ae865f53bd27c45114e6c83bee3 https://git.kernel.org/stable/c/c77ad608df6c091fe64ecb91f41ef7cb465587f1 https://git.kernel.org/stable/c/11a2edb70356a2202dcb7c9c189c8356ab4752cd https://git.kernel.org/stable/c/129dcd3e7d036218db3f59c82d82004b9539ed82 https://git.kernel.org/stable/c/d18b05eda7fa77f02114f15b02c009f28ee42346 https://git.kernel.org/stable/c/59f14875a96ef93f05b82ad3c980605f2 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-39468 – smb: client: fix deadlock in smb2_find_smb_tcon()
https://notcve.org/view.php?id=CVE-2024-39468
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix deadlock in smb2_find_smb_tcon() Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such deadlock. • https://git.kernel.org/stable/c/b055752675cd1d1db4ac9c2750db3dc3e89ea261 https://git.kernel.org/stable/c/21f5dd36e655d25a7b45b61c1e537198b671f720 https://git.kernel.org/stable/c/b09b556e48968317887a11243a5331a7bc00ece5 https://git.kernel.org/stable/c/225de871ddf994f69a57f035709cad9c0ab8615a https://git.kernel.org/stable/c/8d0f5f1ccf675454a833a573c53830a49b7d1a47 https://git.kernel.org/stable/c/02c418774f76a0a36a6195c9dbf8971eb4130a15 •