CVSS: 5.6EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36894 – usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete
https://notcve.org/view.php?id=CVE-2024-36894
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following: DWC3 Gadget FFS Application dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue() There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock. Fix this issue by moving the usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. • https://git.kernel.org/stable/c/2e4c7553cd6f9c68bb741582dcb614edcbeca70f https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311 https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867 https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14 https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb251 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36893 – usb: typec: tcpm: Check for port partner validity before consuming it
https://notcve.org/view.php?id=CVE-2024-36893
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Check for port partner validity before consuming it typec_register_partner() does not guarantee partner registration to always succeed. In the event of failure, port->partner is set to the error value or NULL. Given that port->partner validity is not checked, this results in the following crash: Unable to handle kernel NULL pointer dereference at virtual address xx pc : run_state_machine+0x1bc8/0x1c08 lr : run_state_machine+0x1b90/0x1c08 .. Call trace: run_state_machine+0x1bc8/0x1c08 tcpm_state_machine_work+0x94/0xe4 kthread_worker_fn+0x118/0x328 kthread+0x1d0/0x23c ret_from_fork+0x10/0x20 To prevent the crash, check for port->partner validity before derefencing it in all the call sites. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: verifique la validez del socio del puerto antes de consumirlo. typec_register_partner() no garantiza que el registro del socio sea siempre exitoso. En caso de error, puerto->socio se establece en el valor de error o NULL. • https://git.kernel.org/stable/c/31220bd89c22a18478f52fcd8069e8e2adb8f4f2 https://git.kernel.org/stable/c/9b7cd3fe01f0d03cf5820b351a6be2a6e0a6da6f https://git.kernel.org/stable/c/c97cd0b4b54eb42aed7f6c3c295a2d137f6d2416 https://git.kernel.org/stable/c/2897b36d2482b84f35e659989d5cb4501fb31ccd https://git.kernel.org/stable/c/cbcf107780aecf51aba68488044a416d95060b6d https://git.kernel.org/stable/c/2a07e6f0ad8a6e504a3912cfe8dc859b7d0740a5 https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57 https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-36892 – mm/slub: avoid zeroing outside-object freepointer for single free
https://notcve.org/view.php?id=CVE-2024-36892
In the Linux kernel, the following vulnerability has been resolved: mm/slub: avoid zeroing outside-object freepointer for single free Commit 284f17ac13fe ("mm/slub: handle bulk and single object freeing separately") splits single and bulk object freeing in two functions slab_free() and slab_free_bulk() which leads slab_free() to call slab_free_hook() directly instead of slab_free_freelist_hook(). If `init_on_free` is set, slab_free_hook() zeroes the object. Afterward, if `slub_debug=F` and `CONFIG_SLAB_FREELIST_HARDENED` are set, the do_slab_free() slowpath executes freelist consistency checks and try to decode a zeroed freepointer which leads to a "Freepointer corrupt" detection in check_object(). During bulk free, slab_free_freelist_hook() isn't affected as it always sets it objects freepointer using set_freepointer() to maintain its reconstructed freelist after `init_on_free`. For single free, object's freepointer thus needs to be avoided when stored outside the object if `init_on_free` is set. The freepointer left as is, check_object() may later detect an invalid pointer value due to objects overflow. To reproduce, set `slub_debug=FU init_on_free=1 log_level=7` on the command line of a kernel build with `CONFIG_SLAB_FREELIST_HARDENED=y`. dmesg sample log: [ 10.708715] ============================================================================= [ 10.710323] BUG kmalloc-rnd-05-32 (Tainted: G B T ): Freepointer corrupt [ 10.712695] ----------------------------------------------------------------------------- [ 10.712695] [ 10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2) [ 10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c [ 10.716698] [ 10.716698] Bytes b4 ffff9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.720703] Object ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.720703] Object ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Padding ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Padding ffff9d9a8035667c: 00 00 00 00 .... [ 10.724696] FIX kmalloc-rnd-05-32: Object at 0xffff9d9a80356600 not freed En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slub: evita poner a cero el puntero libre de objetos externos para un solo commit libre 284f17ac13fe ("mm/slub: maneja la liberación masiva y de objetos individuales por separado") divide la liberación de objetos únicos y masivos en dos funciones slab_free() y slab_free_bulk() lo que lleva a slab_free() a llamar a slab_free_hook() directamente en lugar de slab_free_freelist_hook(). Si se establece `init_on_free`, slab_free_hook() pone a cero el objeto. Luego, si se configuran `slub_debug=F` y `CONFIG_SLAB_FREELIST_HARDENED`, la ruta lenta do_slab_free() ejecuta comprobaciones de coherencia de la lista libre e intenta decodificar un freepointer puesto a cero, lo que conduce a una detección de "Freepointer corrupto" en check_object(). Durante la liberación masiva, slab_free_freelist_hook() no se ve afectado ya que siempre establece el puntero libre de sus objetos usando set_freepointer() para mantener su lista libre reconstruida después de `init_on_free`. • https://git.kernel.org/stable/c/284f17ac13fe34ae9eecbe57bb91553374d9b855 https://git.kernel.org/stable/c/56900355485f6e82114b18c812edd57fd7970dcb https://git.kernel.org/stable/c/8f828aa48812ced28aa39cb3cfe55ef2444d03dd •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36891 – maple_tree: fix mas_empty_area_rev() null pointer dereference
https://notcve.org/view.php?id=CVE-2024-36891
In the Linux kernel, the following vulnerability has been resolved: maple_tree: fix mas_empty_area_rev() null pointer dereference Currently the code calls mas_start() followed by mas_data_end() if the maple state is MA_START, but mas_start() may return with the maple state node == NULL. This will lead to a null pointer dereference when checking information in the NULL node, which is done in mas_data_end(). Avoid setting the offset if there is no node by waiting until after the maple state is checked for an empty or single entry state. A user could trigger the events to cause a kernel oops by unmapping all vmas to produce an empty maple tree, then mapping a vma that would cause the scenario described above. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: maple_tree: corrige la desreferencia del puntero nulo mas_empty_area_rev() Actualmente el código llama a mas_start() seguido de mas_data_end() si el estado del arce es MA_START, pero mas_start() puede regresar con el estado del arce nodo == NULL. Esto dará lugar a una desreferencia del puntero nulo al verificar la información en el nodo NULL, lo cual se realiza en mas_data_end(). Evite establecer el desplazamiento si no hay ningún nodo esperando hasta que se verifique el estado del arce para detectar un estado vacío o de entrada única. • https://git.kernel.org/stable/c/54a611b605901c7d5d05b6b8f5d04a6ceb0962aa https://git.kernel.org/stable/c/883e5d542bbdddbddeba60250cb482baf3ae2415 https://git.kernel.org/stable/c/6c9c7c1e63b198a8b979ad963eb21410f10ccb00 https://git.kernel.org/stable/c/f3956791cf526540addd3295e4c1e0f0442486cc https://git.kernel.org/stable/c/955a923d2809803980ff574270f81510112be9cf • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36890 – mm/slab: make __free(kfree) accept error pointers
https://notcve.org/view.php?id=CVE-2024-36890
In the Linux kernel, the following vulnerability has been resolved: mm/slab: make __free(kfree) accept error pointers Currently, if an automatically freed allocation is an error pointer that will lead to a crash. An example of this is in wm831x_gpio_dbg_show(). 171 char *label __free(kfree) = gpiochip_dup_line_label(chip, i); 172 if (IS_ERR(label)) { 173 dev_err(wm831x->dev, "Failed to duplicate label\n"); 174 continue; 175 } The auto clean up function should check for error pointers as well, otherwise we're going to keep hitting issues like this. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slab: make __free(kfree) acepta punteros de error Actualmente, si una asignación liberada automáticamente es un puntero de error que provocará un bloqueo. Un ejemplo de esto está en wm831x_gpio_dbg_show(). 171 caracteres *etiqueta __free(kfree) = gpiochip_dup_line_label(chip, i); 172 if (IS_ERR(etiqueta)) { 173 dev_err(wm831x->dev, "Error al duplicar la etiqueta\n"); 174 continúan; 175 } La función de limpieza automática también debería comprobar si hay indicadores de error; de lo contrario, seguiremos teniendo problemas como este. • https://git.kernel.org/stable/c/3c6cc62ce1265aa5623e2e1b29c0fe258bf6e232 https://git.kernel.org/stable/c/54da6a0924311c7cf5015533991e44fb8eb12773 https://git.kernel.org/stable/c/9f6eb0ab4f95240589ee85fd9886a944cd3645b2 https://git.kernel.org/stable/c/ac6cf3ce9b7d12acb7b528248df5f87caa25fcdc https://git.kernel.org/stable/c/79cbe0be6c0317b215ddd8bd3e32f0afdac48543 https://git.kernel.org/stable/c/cd7eb8f83fcf258f71e293f7fc52a70be8ed0128 •