CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42259 – drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
https://notcve.org/view.php?id=CVE-2024-42259
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) Linux i915 suffers from an out-of-bounds PTE write in vm_fault_gtt() that leads to a PTE use-after-free vulnerability. • https://git.kernel.org/stable/c/c58305af1835095ddc25ee6f548ac05915e66ac5 https://git.kernel.org/stable/c/3e06073d24807f04b4694108a8474decb7b99e60 https://git.kernel.org/stable/c/a256d019eaf044864c7e50312f0a65b323c24f39 https://git.kernel.org/stable/c/50111a8098fb9ade621eeff82228a997d42732ab https://git.kernel.org/stable/c/911f8055f175c82775d0fd8cedcd0b75413f4ba7 https://git.kernel.org/stable/c/e8a68aa842d3f8dd04a46b9d632e5f67fde1da9b https://git.kernel.org/stable/c/4b09513ce93b3dcb590baaaff2ce96f2d098312d https://git.kernel.org/stable/c/ead9289a51ea82eb5b27029fcf4c34b2d •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42258 – mm: huge_memory: use !CONFIG_64BIT to relax huge page alignment on 32 bit machines
https://notcve.org/view.php?id=CVE-2024-42258
In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: use !CONFIG_64BIT to relax huge page alignment on 32 bit machines Yves-Alexis Perez reported commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit") didn't work for x86_32 [1]. It is because x86_32 uses CONFIG_X86_32 instead of CONFIG_32BIT. !CONFIG_64BIT should cover all 32 bit machines. [1] https://lore.kernel.org/linux-mm/CAHbLzkr1LwH3pcTgM+aGQ31ip2bKqiqEQ8=FQB+t2c3dhNKNHA@mail.gmail.com/ • https://git.kernel.org/stable/c/87632bc9ecff5ded93433bc0fca428019bdd1cfe https://git.kernel.org/stable/c/4ef9ad19e17676b9ef071309bc62020e2373705d https://git.kernel.org/stable/c/7432376c913381c5f24d373a87ff629bbde94b47 https://git.kernel.org/stable/c/89f2914dd4b47d2fad3deef0d700f9526d98d11f https://git.kernel.org/stable/c/7e1f4efb8d6140b2ec79bf760c43e1fc186e8dfc https://git.kernel.org/stable/c/d9592025000b3cf26c742f3505da7b83aedc26d5 https://git.kernel.org/stable/c/a5c399fe433a115e9d3693169b5f357f3194af0a https://access.redhat.com/security/cve/CVE-2024-42258 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42257 – ext4: use memtostr_pad() for s_volume_name
https://notcve.org/view.php?id=CVE-2024-42257
In the Linux kernel, the following vulnerability has been resolved: ext4: use memtostr_pad() for s_volume_name As with the other strings in struct ext4_super_block, s_volume_name is not NUL terminated. The other strings were marked in commit 072ebb3bffe6 ("ext4: add nonstring annotations to ext4.h"). Using strscpy() isn't the right replacement for strncpy(); it should use memtostr_pad() instead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: use memtostr_pad() para s_volume_name Al igual que con las otras cadenas en la estructura ext4_super_block, s_volume_name no tiene terminación NUL. Las otras cadenas se marcaron en el commit 072ebb3bffe6 ("ext4: agregue anotaciones que no sean cadenas a ext4.h"). • https://git.kernel.org/stable/c/744a56389f7398f286231e062c2e63f0de01bcc6 https://git.kernel.org/stable/c/4378be89ddb7de88d984b67ecfd6191686c42817 https://git.kernel.org/stable/c/be27cd64461c45a6088a91a04eba5cd44e1767ef •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42256 – cifs: Fix server re-repick on subrequest retry
https://notcve.org/view.php?id=CVE-2024-42256
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix server re-repick on subrequest retry When a subrequest is marked for needing retry, netfs will call cifs_prepare_write() which will make cifs repick the server for the op before renegotiating credits; it then calls cifs_issue_write() which invokes smb2_async_writev() - which re-repicks the server. If a different server is then selected, this causes the increment of server->in_flight to happen against one record and the decrement to happen against another, leading to misaccounting. Fix this by just removing the repick code in smb2_async_writev(). As this is only called from netfslib-driven code, cifs_prepare_write() should always have been called first, and so server should never be NULL and the preparatory step is repeated in the event that we do a retry. The problem manifests as a warning looking something like: WARNING: CPU: 4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs] ... RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs] ... smb2_writev_callback+0x334/0x560 [cifs] cifs_demultiplex_thread+0x77a/0x11b0 [cifs] kthread+0x187/0x1d0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Which may be triggered by a number of different xfstests running against an Azure server in multichannel mode. generic/249 seems the most repeatable, but generic/215, generic/249 and generic/308 may also show it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: corrige la repetición del servidor en el reintento de subrequest Cuando se marca una subrequest para necesitar un reintento, netfs llamará a cifs_prepare_write(), lo que hará que cifs vuelva a seleccionar el servidor para la operación antes de renegociar los créditos; luego llama a cifs_issue_write(), que invoca a smb2_async_writev(), que vuelve a seleccionar el servidor. Si luego se selecciona un servidor diferente, esto hace que el incremento de server->in_flight ocurra en un registro y la disminución en otro, lo que lleva a una contabilidad errónea. • https://git.kernel.org/stable/c/3ee1a1fc39819906f04d6c62c180e760cd3a689d https://git.kernel.org/stable/c/b1d0a566769b6fb3795b5289fc1daf9e0638d97a https://git.kernel.org/stable/c/de40579b903883274fe203865f29d66b168b7236 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42255 – tpm: Use auth only after NULL check in tpm_buf_check_hmac_response()
https://notcve.org/view.php?id=CVE-2024-42255
In the Linux kernel, the following vulnerability has been resolved: tpm: Use auth only after NULL check in tpm_buf_check_hmac_response() Dereference auth after NULL check in tpm_buf_check_hmac_response(). Otherwise, unless tpm2_sessions_init() was called, a call can cause NULL dereference, when TCG_TPM2_HMAC is enabled. [jarkko: adjusted the commit message.] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm: use autenticación solo después de la verificación NULL en tpm_buf_check_hmac_response() Desreferenciar la autenticación después de la verificación NULL en tpm_buf_check_hmac_response(). De lo contrario, a menos que se haya llamado a tpm2_sessions_init(), una llamada puede causar una desreferencia NULL, cuando TCG_TPM2_HMAC está habilitado. [jarkko: ajustó el mensaje de confirmación.] • https://git.kernel.org/stable/c/7ca110f2679b7d1f3ac1afc90e6ffbf0af3edf0d https://git.kernel.org/stable/c/b9afbb9a0c734197c59c43610071041044bf1562 https://git.kernel.org/stable/c/7dc357d343f134bf59815ff6098b93503ec8a23b •