CVE-2024-53114 – x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client
https://notcve.org/view.php?id=CVE-2024-53114
In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/CPU/AMD: Borrar VMLOAD/VMSAVE virtualizado en el cliente Zen4 Varios SoC de cliente Zen4 anuncian la capacidad de usar VMLOAD/VMSAVE virtualizado, pero se informa que el uso de estas instrucciones es la causa de un reinicio aleatorio del host. Estas instrucciones no están destinadas a ser anunciadas en el cliente Zen4, por lo que se debe borrar la capacidad. • https://git.kernel.org/stable/c/00c713f84f477a85e524f34aad8fbd11a1c051f0 https://git.kernel.org/stable/c/a5ca1dc46a6b610dd4627d8b633d6c84f9724ef0 •
CVE-2024-53113 – mm: fix NULL pointer dereference in alloc_pages_bulk_noprof
https://notcve.org/view.php?id=CVE-2024-53113
In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") and commit df76cee6bbeb ("mm, page_alloc: remove redundant checks from alloc fastpath"). To fix it, check NULL pointer for preferred_zoneref->zone. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: corregir la desreferencia de puntero NULL en alloc_pages_bulk_noprof Activamos una desreferencia de puntero NULL para ac.preferred_zoneref->zone en alloc_pages_bulk_noprof() cuando la tarea se migra entre conjuntos de CPU. • https://git.kernel.org/stable/c/387ba26fb1cb9be9e35dc14a6d97188e916eda05 https://git.kernel.org/stable/c/6addb2d9501ec866d7b3a3b4e665307c437e9be2 https://git.kernel.org/stable/c/d0f16cec79774c3132df006cf771eddd89d08f58 https://git.kernel.org/stable/c/31502374627ba9ec3e710dbd0bb00457cc6d2c19 https://git.kernel.org/stable/c/8ce41b0f9d77cca074df25afd39b86e2ee3aa68e •
CVE-2024-53112 – ocfs2: uncache inode which has failed entering the group
https://notcve.org/view.php?id=CVE-2024-53112
In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: <TASK> ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? • https://git.kernel.org/stable/c/7909f2bf835376a20d6dbf853eb459a27566eba2 https://git.kernel.org/stable/c/620d22598110b0d0cb97a3fcca65fc473ea86e73 https://git.kernel.org/stable/c/843dfc804af4b338ead42331dd58081b428ecdf8 https://git.kernel.org/stable/c/b751c50e19d66cfb7360c0b55cf17b0722252d12 https://git.kernel.org/stable/c/737f34137844d6572ab7d473c998c7f977ff30eb •
CVE-2024-53111 – mm/mremap: fix address wraparound in move_page_tables()
https://notcve.org/view.php?id=CVE-2024-53111
In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an "orig_old_start" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include <stdlib.h> #include <stdio.h> #include <err.h> #include <sys/mman.h> #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, "mmap 1"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, "mmap 2"); *p1 = 0x41; printf("first char is 0x%02hhx\n", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf("mremap() failed; first char is 0x%02hhx\n", *p1); } else { printf("mremap() succeeded; first char is 0x%02hhx\n", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ``` En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mremap: se corrige el envoltorio de direcciones en move_page_tables() En plataformas de 32 bits, es posible que la expresión `len + old_addr < old_end` sea un falso positivo si `len + old_addr` realiza un envoltorio. `old_addr` es el cursor en el rango antiguo hasta el cual se han movido las entradas de la tabla de páginas; por lo que si la operación tuvo éxito, `old_addr` es el *final* de la región antigua, y agregarle `len` puede realizar un envoltorio. • https://git.kernel.org/stable/c/af8ca1c149069176e6322a77b532e3ffd99ccffe https://git.kernel.org/stable/c/909543dc279a91122fb08e4653a72b82f0ad28f4 https://git.kernel.org/stable/c/a4a282daf1a190f03790bf163458ea3c8d28d217 •
CVE-2024-53110 – vp_vdpa: fix id_table array not null terminated error
https://notcve.org/view.php?id=CVE-2024-53110
In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vp_vdpa: se corrige el error de matriz id_table no terminada en nulo. Asigne un virtio_device_id adicional como terminador nulo; de lo contrario, vdpa_mgmtdev_get_classes() puede iterar varias veces y visitar memoria no definida. • https://git.kernel.org/stable/c/ffbda8e9df10d1784d5427ec199e7d8308e3763f https://git.kernel.org/stable/c/870d68fe17b5d9032049dcad98b5781a344a8657 https://git.kernel.org/stable/c/c4d64534d4b1c47d2f1ce427497f971ad4735aae https://git.kernel.org/stable/c/0a886489d274596ad1a80789d3a773503210a615 https://git.kernel.org/stable/c/4e39ecadf1d2a08187139619f1f314b64ba7d947 •