CVE-2024-42102

{"id": "CVE-2024-42102", "cveTags": [], "metrics": {}, "published": "2024-07-30T08:15:02.733", "references": [{"url": "https://git.kernel.org/stable/c/000099d71648504fb9c7a4616f92c2b70c3e44ec", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/145faa3d03688cbb7bbaaecbd84c01539852942c", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/23a28f5f3f6ca1e4184bd0e9631cd0944cf1c807", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/253f9ea7e8e53a5176bd80ceb174907b10724c1a", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/2820005edae13b140f2d54267d1bd6bb23915f59", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/30139c702048f1097342a31302cbd3d478f50c63", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/cbbe17a324437c0ff99881a3ee453da45b228a00", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/f6620df12cb6bdcad671d269debbb23573502f9d", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again\"\n\nPatch series \"mm: Avoid possible overflows in dirty throttling\".\n\nDirty throttling logic assumes dirty limits in page units fit into\n32-bits. This patch series makes sure this is true (see patch 2/2 for\nmore details).\n\n\nThis patch (of 2):\n\nThis reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.\n\nThe commit is broken in several ways. Firstly, the removed (u64) cast\nfrom the multiplication will introduce a multiplication overflow on 32-bit\narchs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the\ndefault settings with 4GB of RAM will trigger this). Secondly, the\ndiv64_u64() is unnecessarily expensive on 32-bit archs. We have\ndiv64_ul() in case we want to be safe & cheap. Thirdly, if dirty\nthresholds are larger than 1<<32 pages, then dirty balancing is going to\nblow up in many other spectacular ways anyway so trying to fix one\npossible overflow is just moot."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir \"mm/writeback: corrige la posible divisi\u00f3n por cero en wb_dirty_limits(), nuevamente\" Patch series \"mm: evita posibles desbordamientos en la aceleraci\u00f3n sucia\". La l\u00f3gica de limitaci\u00f3n sucia supone que los l\u00edmites sucios en las unidades de p\u00e1ginas caben en 32 bits. Esta serie de parches garantiza que esto sea cierto (consulte el parche 2/2 para obtener m\u00e1s detalles). Este parche (de 2): esto revierte la confirmaci\u00f3n 9319b647902cbd5cc884ac08a8a6d54ce111fc78. El compromiso se rompe de varias maneras. En primer lugar, la conversi\u00f3n eliminada (u64) de la multiplicaci\u00f3n introducir\u00e1 un desbordamiento de multiplicaci\u00f3n en arcos de 32 bits si wb_thresh * bg_thresh &gt;= 1&lt;&lt;32 (lo cual es realmente com\u00fan; la configuraci\u00f3n predeterminada con 4 GB de RAM activar\u00e1 esto). En segundo lugar, div64_u64() es innecesariamente caro en arcos de 32 bits. Tenemos div64_ul() en caso de que queramos ser seguros y econ\u00f3micos. En tercer lugar, si los umbrales sucios son mayores que 1&lt;&lt;32 p\u00e1ginas, entonces el equilibrio sucio explotar\u00e1 de muchas otras maneras espectaculares de todos modos, por lo que intentar solucionar un posible desbordamiento es discutible."}], "lastModified": "2024-07-30T13:32:45.943", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}