CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-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 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-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 •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-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 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-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 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-53109 – nommu: pass NULL argument to vma_iter_prealloc()
https://notcve.org/view.php?id=CVE-2024-53109
In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nommu: pasar argumento NULL a vma_iter_prealloc(). Al eliminar una entrada vma de un árbol maple, tiene que pasar NULL a vma_iter_prealloc() para calcular el estado interno del árbol, pero pasó un argumento incorrecto. Como resultado, los kernels nommu fallaban al acceder a un iterador vma, como acct_collect() que lee el tamaño de las entradas vma después de do_munmap(). • https://git.kernel.org/stable/c/b5df09226450165c434084d346fcb6d4858b0d52 https://git.kernel.org/stable/c/8bbf0ab631cdf1dade6745f137cff98751e6ced7 https://git.kernel.org/stable/c/aceaf33b7666b72dfb86e0aa977be81e3bcbc727 https://git.kernel.org/stable/c/247d720b2c5d22f7281437fd6054a138256986ba •