CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35879 – of: dynamic: Synchronize of_changeset_destroy() with the devlink removals
https://notcve.org/view.php?id=CVE-2024-35879
In the Linux kernel, the following vulnerability has been resolved: of: dynamic: Synchronize of_changeset_destroy() with the devlink removals In the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove() During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but __of_changeset_entry_destroy() can raise warnings related to missing of_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ... Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached of_node) is done by a job queued in a workqueue and so, it is done asynchronously with respect to function calls. When the warning is present, of_node_put() will be called but wrongly too late from the workqueue job. In order to be sure that any ongoing devlink removals are done before the of_node destruction, synchronize the of_changeset_destroy() with the devlink removals. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: of:dynamic: Sincronizar of_changeset_destroy() con las eliminaciones de devlink En la siguiente secuencia: 1) of_platform_depopulate() 2) of_overlay_remove() Durante el paso 1, los dispositivos se destruyen y los devlinks son remoto. Durante el paso 2, los nodos OF se destruyen, pero __of_changeset_entry_destroy() puede generar advertencias relacionadas con la falta de of_node_put(): ERROR: pérdida de memoria, recuento esperado 1 en lugar de 2... De hecho, durante las eliminaciones de devlink realizadas en el paso 1, la eliminación La liberación del dispositivo (y el of_node adjunto) se realiza mediante un trabajo en cola en una cola de trabajo y, por lo tanto, se realiza de forma asincrónica con respecto a las llamadas a funciones. Cuando la advertencia está presente, se llamará a of_node_put() pero erróneamente demasiado tarde desde el trabajo de la cola de trabajo. • https://git.kernel.org/stable/c/d007150b4e15bfcb8d36cfd88a5645d42e44d383 https://git.kernel.org/stable/c/80dd33cf72d1ab4f0af303f1fa242c6d6c8d328f https://git.kernel.org/stable/c/252c23915546863685ecc68cb3a39e7e80c6c9d4 https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf0b111c7a https://git.kernel.org/stable/c/3ee2424107546d882e1ddd75333ca9c32879908c https://git.kernel.org/stable/c/7b6df050c45a1ea158fd50bc32a8e1447dd1e951 https://git.kernel.org/stable/c/801c8b8ec5bfb3519566dff16a5ecd48302fca82 https://git.kernel.org/stable/c/ae6d76e4f06c37a623e357e79d49b1741 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35878 – of: module: prevent NULL pointer dereference in vsnprintf()
https://notcve.org/view.php?id=CVE-2024-35878
In the Linux kernel, the following vulnerability has been resolved: of: module: prevent NULL pointer dereference in vsnprintf() In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: de: módulo: evita la desreferencia del puntero NULL en vsnprintf() En of_modalias(), podemos pasar los parámetros str y len que provocarían un kernel ups en vsnprintf() ya que solo permite pasar un ptr NULL cuando la longitud también es 0. Además, necesitamos filtrar los valores negativos del parámetro len ya que estos darán como resultado un búfer realmente enorme ya que snprintf() toma el parámetro size_t mientras que el nuestro es ssize_t... Encontrado por el Centro de verificación de Linux (linuxtesting.org) con la herramienta de análisis estático Svace. • https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898 https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987 https://access.redhat.com/security/cve/CVE-2024-35878 https://bugzilla.redhat.com/show_bug.cgi?id=2281718 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35877 – x86/mm/pat: fix VM_PAT handling in COW mappings
https://notcve.org/view.php?id=CVE-2024-35877
In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(). In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory. To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that. We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size. For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios. Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn(): <--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h> int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; } <--- C reproducer ---> On a system with 16 GiB RAM and swap configured: # . • https://git.kernel.org/stable/c/5899329b19100c0b82dc78e9b21ed8b920c9ffb3 https://git.kernel.org/stable/c/f18681daaec9665a15c5e7e0f591aad5d0ac622b https://git.kernel.org/stable/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173 https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4 https://git.kernel.org/stable/c/7cfee26d1950250b14c5cb0a37b142f3fcc6396a https://git.kernel.org/stable/c/97e93367e82752e475a33839a80b33bdbef1209f https://git.kernel.org/stable/c/51b7841f3fe84606ec0bd8da859d22e05e5419ec https://git.kernel.org/stable/c/1341e4b32e1fb1b0acd002ccd56f07bd3 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35875 – x86/coco: Require seeding RNG with RDRAND on CoCo systems
https://notcve.org/view.php?id=CVE-2024-35875
In the Linux kernel, the following vulnerability has been resolved: x86/coco: Require seeding RNG with RDRAND on CoCo systems There are few uses of CoCo that don't rely on working cryptography and hence a working RNG. Unfortunately, the CoCo threat model means that the VM host cannot be trusted and may actively work against guests to extract secrets or manipulate computation. Since a malicious host can modify or observe nearly all inputs to guests, the only remaining source of entropy for CoCo guests is RDRAND. If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole is meant to gracefully continue on gathering entropy from other sources, but since there aren't other sources on CoCo, this is catastrophic. This is mostly a concern at boot time when initially seeding the RNG, as after that the consequences of a broken RDRAND are much more theoretical. So, try at boot to seed the RNG using 256 bits of RDRAND output. If this fails, panic(). This will also trigger if the system is booted without RDRAND, as RDRAND is essential for a safe CoCo boot. Add this deliberately to be "just a CoCo x86 driver feature" and not part of the RNG itself. • https://git.kernel.org/stable/c/22943e4fe4b3a2dcbadc3d38d5bf840bbdbfe374 https://git.kernel.org/stable/c/453b5f2dec276c1bb4ea078bf8c0da57ee4627e5 https://git.kernel.org/stable/c/08044b08b37528b82f70a87576c692b4e4b7716e https://git.kernel.org/stable/c/99485c4c026f024e7cb82da84c7951dbe3deb584 https://access.redhat.com/security/cve/CVE-2024-35875 https://bugzilla.redhat.com/show_bug.cgi?id=2281727 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35872 – mm/secretmem: fix GUP-fast succeeding on secretmem folios
https://notcve.org/view.php?id=CVE-2024-35872
In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix GUP-fast succeeding on secretmem folios folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/secretmem: corrige el éxito rápido de GUP en folios secretmem folio_is_secretmem() actualmente depende de que los folios secretmem sean folios LRU, para guardar algunos ciclos. Sin embargo, las publicaciones pueden residir en un lote de publicaciones sin el indicador LRU establecido o tener su indicador LRU borrado temporalmente. • https://git.kernel.org/stable/c/1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48 https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8 https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5 https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706 https://access.redhat.com/security/cve/CVE-2024-35872 https://bugzilla.redhat.com/show_bug.cgi?id=2281736 •