CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52609 – binder: fix race between mmput() and do_exit()
https://notcve.org/view.php?id=CVE-2023-52609
In the Linux kernel, the following vulnerability has been resolved: binder: fix race between mmput() and do_exit() Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A. Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() | In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead). This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. • https://git.kernel.org/stable/c/457b9a6f09f011ebcb9b52cc203a6331a6fc2de7 https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608 https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097 https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918 https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9 https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3 https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47135 – mt76: mt7921: fix possible AOOB issue in mt7921_mcu_tx_rate_report
https://notcve.org/view.php?id=CVE-2021-47135
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix possible AOOB issue in mt7921_mcu_tx_rate_report Fix possible array out of bound access in mt7921_mcu_tx_rate_report. Remove unnecessary varibable in mt7921_mcu_tx_rate_report En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: mt7921: solucione un posible problema de AOOB en mt7921_mcu_tx_rate_report. Corrija un posible acceso fuera de los límites a la matriz en mt7921_mcu_tx_rate_report. Eliminar variables innecesarias en mt7921_mcu_tx_rate_report • https://git.kernel.org/stable/c/1c099ab44727c8e42fe4de4d91b53cec3ef02860 https://git.kernel.org/stable/c/6919e8a24e70b6ba148fe07f44f835bcdd1a8d02 https://git.kernel.org/stable/c/d874e6c06952382897d35bf4094193cd44ae91bd •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47134 – efi/fdt: fix panic when no valid fdt found
https://notcve.org/view.php?id=CVE-2021-47134
In the Linux kernel, the following vulnerability has been resolved: efi/fdt: fix panic when no valid fdt found setup_arch() would invoke efi_init()->efi_get_fdt_params(). If no valid fdt found then initial_boot_params will be null. So we should stop further fdt processing here. I encountered this issue on risc-v. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: efi/fdt: corrige el pánico cuando no se encuentra un fdt válido. setup_arch() invocaría efi_init()->efi_get_fdt_params(). • https://git.kernel.org/stable/c/b91540d52a08b65eb6a2b09132e1bd54fa82754c https://git.kernel.org/stable/c/5148066edbdc89c6fe5bc419c31a5c22e5f83bdb https://git.kernel.org/stable/c/8a7e8b4e5631a03ea2fee27957857a56612108ca https://git.kernel.org/stable/c/668a84c1bfb2b3fd5a10847825a854d63fac7baa •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47133 – HID: amd_sfh: Fix memory leak in amd_sfh_work
https://notcve.org/view.php?id=CVE-2021-47133
In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Fix memory leak in amd_sfh_work Kmemleak tool detected a memory leak in the amd_sfh driver. ==================== unreferenced object 0xffff88810228ada0 (size 32): comm "insmod", pid 3968, jiffies 4295056001 (age 775.792s) hex dump (first 32 bytes): 00 20 73 1f 81 88 ff ff 00 01 00 00 00 00 ad de . s............. 22 01 00 00 00 00 ad de 01 00 02 00 00 00 00 00 "............... backtrace: [<000000007b4c8799>] kmem_cache_alloc_trace+0x163/0x4f0 [<0000000005326893>] amd_sfh_get_report+0xa4/0x1d0 [amd_sfh] [<000000002a9e5ec4>] amdtp_hid_request+0x62/0x80 [amd_sfh] [<00000000b8a95807>] sensor_hub_get_feature+0x145/0x270 [hid_sensor_hub] [<00000000fda054ee>] hid_sensor_parse_common_attributes+0x215/0x460 [hid_sensor_iio_common] [<0000000021279ecf>] hid_accel_3d_probe+0xff/0x4a0 [hid_sensor_accel_3d] [<00000000915760ce>] platform_probe+0x6a/0xd0 [<0000000060258a1f>] really_probe+0x192/0x620 [<00000000fa812f2d>] driver_probe_device+0x14a/0x1d0 [<000000005e79f7fd>] __device_attach_driver+0xbd/0x110 [<0000000070d15018>] bus_for_each_drv+0xfd/0x160 [<0000000013a3c312>] __device_attach+0x18b/0x220 [<000000008c7b4afc>] device_initial_probe+0x13/0x20 [<00000000e6e99665>] bus_probe_device+0xfe/0x120 [<00000000833fa90b>] device_add+0x6a6/0xe00 [<00000000fa901078>] platform_device_add+0x180/0x380 ==================== The fix is to freeing request_list entry once the processed entry is removed from the request_list. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: amd_sfh: Reparar pérdida de memoria en amd_sfh_work La herramienta Kmemleak detectó una pérdida de memoria en el controlador amd_sfh. ==================== objeto sin referencia 0xffff88810228ada0 (tamaño 32): comm "insmod", pid 3968, jiffies 4295056001 (edad 775,792 s) volcado hexadecimal (primeros 32 bytes) : 00 20 73 1f 81 88 ff ff 00 01 00 00 00 00 ad de . s................. 22 01 00 00 00 00 ad de 01 00 02 00 00 00 00 00 "................. retroceso: [< 000000007b4c8799>] kmem_cache_alloc_trace+0x163/0x4f0 [<0000000005326893>] amd_sfh_get_report+0xa4/0x1d0 [amd_sfh] [<000000002a9e5ec4>] amdtp_hid_request+0x6 2/0x80 [amd_sfh] [<00000000b8a95807>] sensor_hub_get_feature+0x145/0x270 [hid_sensor_hub] [<00000000fda054ee >] hid_sensor_parse_common_attributes+0x215/0x460 [hid_sensor_iio_common] [<0000000021279ecf>] hid_accel_3d_probe+0xff/0x4a0 [hid_sensor_accel_3d] [<00000000915760ce>] platform_probe+0x6a/0xd0 [ <0000000060258a1f>] very_probe+0x192/0x620 [<00000000fa812f2d>] driver_probe_device+ 0x14a/0x1d0 [<000000005e79f7fd>] __device_attach_driver+0xbd/0x110 [<0000000070d15018>] bus_for_each_drv+0xfd/0x160 [<0000000013a3c312>] __device_attach+0x1 8b/0x220 [<000000008c7b4afc>] dispositivo_sonda_inicial+0x13/0x20 [<00000000e6e99665>] bus_probe_dispositivo+ 0xfe/0x120 [<00000000833fa90b>] device_add+0x6a6/0xe00 [<00000000fa901078>] platform_device_add+0x180/0x380 ===================== La solución es liberar la entrada request_list una vez que la entrada procesada se elimina de request_list. • https://git.kernel.org/stable/c/4b2c53d93a4bc9d52cc0ec354629cfc9dc217f93 https://git.kernel.org/stable/c/29beadea66a226d744d5ffdcde6b984623053d24 https://git.kernel.org/stable/c/5ad755fd2b326aa2bc8910b0eb351ee6aece21b1 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47132 – mptcp: fix sk_forward_memory corruption on retransmission
https://notcve.org/view.php?id=CVE-2021-47132
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix sk_forward_memory corruption on retransmission MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige la corrupción de sk_forward_memory en la retransmisión El manejo de MPTCP sk_forward_memory es un poco especial, ya que dicho campo está protegido por el socket msk spin_lock, en lugar del bloqueo de socket simple. Actualmente tenemos una ruta de código que actualiza dicho campo sin manejar el bloqueo relevante: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Varios ayudantes en __mptcp_clean_una_wakeup() actualizarán sk_forward_alloc, posiblemente causando dicha corrupción de campo, según lo informado por Matthieu. Solucione el problema proporcionando y utilizando una nueva variante de la función culpada que adquiere explícitamente el bloqueo de giro msk. • https://git.kernel.org/stable/c/64b9cea7a0afe579dd2682f1f1c04f2e4e72fd25 https://git.kernel.org/stable/c/96db8ffef07516a6d7414b6988f2a4298a839977 https://git.kernel.org/stable/c/b9c78b1a95966a7bd2ddae05b73eafc0cda4fba3 https://git.kernel.org/stable/c/b5941f066b4ca331db225a976dae1d6ca8cf0ae3 •