CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26984 – nouveau: fix instmem race condition around ptr stores
https://notcve.org/view.php?id=CVE-2024-26984
In some conditions, a race condition can cause a NULL pointer dereference, resulting in a denial of service. • https://git.kernel.org/stable/c/be55287aa5ba6895e9d4d3ed2f08a1be7a065957 https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9 https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7 https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716 https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572 https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039 https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525 https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26973 – fat: fix uninitialized field in nostale filehandles
https://notcve.org/view.php?id=CVE-2024-26973
Sin embargo, la longitud del identificador del archivo debe ser múltiplo de 4, por lo que el identificador del archivo tiene en realidad 12 bytes de longitud y los dos últimos bytes permanecen sin inicializar. • https://git.kernel.org/stable/c/ea3983ace6b79c96e6ab3d3837e2eaf81ab881e2 https://git.kernel.org/stable/c/9840d1897e28f8733cc1e38f97e044f987dc0a63 https://git.kernel.org/stable/c/f52d7663a10a1266a2d3871a6dd8fd111edc549f https://git.kernel.org/stable/c/a276c595c3a629170b0f052a3724f755d7c6adc6 https://git.kernel.org/stable/c/b7fb63e807c6dadf7ecc1d43448c4f1711d7eeee https://git.kernel.org/stable/c/c8cc05de8e6b5612b6e9f92c385c1a064b0db375 https://git.kernel.org/stable/c/03a7e3f2ba3ca25f1da1d3898709a08db14c1abb https://git.kernel.org/stable/c/74f852654b8b7866f15323685f1e178d3 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26972 – ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
https://notcve.org/view.php?id=CVE-2024-26972
El siguiente kmemleak es fácil de reproducir inyectando un error en ubifs_jnl_update() al realizar un enlace simbólico en un escenario de cifrado: objeto sin referencia 0xffff888103da3d98 (tamaño 8): comm "ln", pid 1692, jiffies 4294914701 (edad 12.045 s) backtrace: kmemdup+0x32/ 0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 Hay dos formas de solucionarlo: 1. • https://git.kernel.org/stable/c/2c58d548f5706d085c4b009f6abb945220460632 https://git.kernel.org/stable/c/3faea7810e2b3e9a9a92ef42d7e5feaeb8ff7133 https://git.kernel.org/stable/c/62b5ae00c2b835639002ce898ccb5d82c51073ae https://git.kernel.org/stable/c/6379b44cdcd67f5f5d986b73953e99700591edfa •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26961 – mac802154: fix llsec key resources release in mac802154_llsec_key_del
https://notcve.org/view.php?id=CVE-2024-26961
A flaw was found in the Linux Kernel where resources are improperly managed in IEEE 802.15.4 networking, leading to a potential use-after-free issue, resulting in a denial of service. • https://git.kernel.org/stable/c/5d637d5aabd85132bd85779677d8acb708e0ed90 https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531 https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821 https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88 https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1 https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b • CWE-459: Incomplete Cleanup •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26958 – nfs: fix UAF in direct writes
https://notcve.org/view.php?id=CVE-2024-26958
__btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 Esto se debe a que estamos completando nfs_direct_request dos veces seguidas. La fuente de esto es cuando tenemos que enviar nuestras solicitudes de confirmación, las procesamos y las enviamos, y luego en la ruta de finalización para las solicitudes de confirmación tenemos if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq); Sin embargo, dado que enviamos solicitudes asincrónicas, a veces tenemos una que se completa antes de enviar la siguiente, por lo que terminamos llamando a complete en nfs_direct_request dos veces. El único otro lugar donde usamos nfs_generic_commit_list() es en __nfs_commit_inode, que envuelve esta llamada en nfs_commit_begin(); nfs_commit_end(); Este es un patrón común para este estilo de manejo de finalización, uno que también se repite en el código directo con llamadas get_dreq()/put_dreq() en el lugar donde procesamos eventos, así como en las rutas de finalización. • https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5 https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3 https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605 https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95 https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af https://lists.debian.org/debian-lts-announce/2024/06/ •