CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47415 – iwlwifi: mvm: Fix possible NULL dereference
https://notcve.org/view.php?id=CVE-2021-47415
In the Linux kernel, the following vulnerability has been resolved: iwlwifi: mvm: Fix possible NULL dereference In __iwl_mvm_remove_time_event() check that 'te_data->vif' is NULL before dereferencing it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iwlwifi: mvm: Corrige posible desreferencia NULL En __iwl_mvm_remove_time_event() comprueba que 'te_data->vif' sea NULL antes de desreferenciarlo. • https://git.kernel.org/stable/c/7b3954a1d69a992a781e71036950f9254f8147f6 https://git.kernel.org/stable/c/432d8185e9ffce97e3866ca71c39b0807a456920 https://git.kernel.org/stable/c/24d5f16e407b75bc59d5419b957a9cab423b2681 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47414 – riscv: Flush current cpu icache before other cpus
https://notcve.org/view.php?id=CVE-2021-47414
In the Linux kernel, the following vulnerability has been resolved: riscv: Flush current cpu icache before other cpus On SiFive Unmatched, I recently fell onto the following BUG when booting: [ 0.000000] ftrace: allocating 36610 entries in 144 pages [ 0.000000] Oops - illegal instruction [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5 [ 0.000000] Hardware name: SiFive HiFive Unmatched A00 (DT) [ 0.000000] epc : riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10 [ 0.000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000 [ 0.000000] t1 : 0000000000000004 t2 : 0000000000000000 s0 : ffffffff81803e60 [ 0.000000] s1 : 0000000000000000 a0 : ffffffff81a22238 a1 : ffffffff81803e10 [ 0.000000] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.000000] a5 : 0000000000000000 a6 : ffffffff8000989c a7 : 0000000052464e43 [ 0.000000] s2 : ffffffff81a220c8 s3 : 0000000000000000 s4 : 0000000000000000 [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001 [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000 [ 0.000000] s11: 0000000000000004 t3 : 0000000000000001 t4 : 0000000000000008 [ 0.000000] t5 : ffffffcf04000808 t6 : ffffffe3ffddf188 [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000002 [ 0.000000] [<ffffffff80007240>] riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] [<ffffffff80009474>] sbi_remote_fence_i+0x1e/0x26 [ 0.000000] [<ffffffff8000b8f4>] flush_icache_all+0x12/0x1a [ 0.000000] [<ffffffff8000666c>] patch_text_nosync+0x26/0x32 [ 0.000000] [<ffffffff8000884e>] ftrace_init_nop+0x52/0x8c [ 0.000000] [<ffffffff800f051e>] ftrace_process_locs.isra.0+0x29c/0x360 [ 0.000000] [<ffffffff80a0e3c6>] ftrace_init+0x80/0x130 [ 0.000000] [<ffffffff80a00f8c>] start_kernel+0x5c4/0x8f6 [ 0.000000] ---[ end trace f67eb9af4d8d492b ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- While ftrace is looping over a list of addresses to patch, it always failed when patching the same function: riscv_cpuid_to_hartid_mask. Looking at the backtrace, the illegal instruction is encountered in this same function. However, patch_text_nosync, after patching the instructions, calls flush_icache_range. But looking at what happens in this function: flush_icache_range -> flush_icache_all -> sbi_remote_fence_i -> __sbi_rfence_v02 -> riscv_cpuid_to_hartid_mask The icache and dcache of the current cpu are never synchronized between the patching of riscv_cpuid_to_hartid_mask and calling this same function. So fix this by flushing the current cpu's icache before asking for the other cpus to do the same. • https://git.kernel.org/stable/c/fab957c11efe2f405e08b9f0d080524bc2631428 https://git.kernel.org/stable/c/427faa29e06f0709476ea1bd59758f997ec8b64e https://git.kernel.org/stable/c/f1c7aa87c423e765e3862349c2f095fdfccdd9b3 https://git.kernel.org/stable/c/bb8958d5dc79acbd071397abb57b8756375fe1ce •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47413 – usb: chipidea: ci_hdrc_imx: Also search for 'phys' phandle
https://notcve.org/view.php?id=CVE-2021-47413
In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: ci_hdrc_imx: Also search for 'phys' phandle When passing 'phys' in the devicetree to describe the USB PHY phandle (which is the recommended way according to Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt) the following NULL pointer dereference is observed on i.MX7 and i.MX8MM: [ 1.489344] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [ 1.498170] Mem abort info: [ 1.500966] ESR = 0x96000044 [ 1.504030] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.509356] SET = 0, FnV = 0 [ 1.512416] EA = 0, S1PTW = 0 [ 1.515569] FSC = 0x04: level 0 translation fault [ 1.520458] Data abort info: [ 1.523349] ISV = 0, ISS = 0x00000044 [ 1.527196] CM = 0, WnR = 1 [ 1.530176] [0000000000000098] user address but active_mm is swapper [ 1.536544] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 1.542125] Modules linked in: [ 1.545190] CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.14.0-dirty #3 [ 1.551901] Hardware name: Kontron i.MX8MM N801X S (DT) [ 1.557133] Workqueue: events_unbound deferred_probe_work_func [ 1.562984] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 1.568998] pc : imx7d_charger_detection+0x3f0/0x510 [ 1.573973] lr : imx7d_charger_detection+0x22c/0x510 This happens because the charger functions check for the phy presence inside the imx_usbmisc_data structure (data->usb_phy), but the chipidea core populates the usb_phy passed via 'phys' inside 'struct ci_hdrc' (ci->usb_phy) instead. This causes the NULL pointer dereference inside imx7d_charger_detection(). Fix it by also searching for 'phys' in case 'fsl,usbphy' is not found. Tested on a imx7s-warp board. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: ci_hdrc_imx: también busque 'phys' phandle. Al pasar 'phys' en el árbol de dispositivos para describir el phandle USB PHY (que es la forma recomendada según Documentation/devicetree /bindings/usb/ci-hdrc-usb2.txt) se observa la siguiente desreferencia del puntero NULL en i.MX7 e i.MX8MM: [1.489344] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000098 [1.498170] Información de cancelación de memoria: [ 1.500966] ESR = 0x96000044 [ 1.504030] EC = 0x25: DABT (EL actual), IL = 32 bits [ 1.509356] SET = 0, FnV = 0 [ 1.512416] EA = 0, S1PTW = 0 [ 1.515569] FSC = 0x04: error de traducción de nivel 0 [1.520458] Información de cancelación de datos: [1.523349] ISV = 0, ISS = 0x00000044 [1.527196] CM = 0, WnR = 1 [1.530176] [0000000000000098] dirección de usuario pero active_mm es intercambiador [1.536544 ] Error interno: Ups : 96000044 [#1] PREEMPT SMP [ 1.542125] Módulos vinculados en: [ 1.545190] CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.14.0-dirty #3 [ 1.551901] Nombre de hardware: Kontron i.MX8MM N801X S (DT) [1.557133] Cola de trabajo: events_unbound deferred_probe_work_func [1.562984] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [1.568998] pc: imx7d_charger_detection+0x3f0/0x510 [ 1. 573973] lr: imx7d_charger_detection+0x22c /0x510 Esto sucede porque las funciones del cargador verifican la presencia de phy dentro de la estructura imx_usbmisc_data (data->usb_phy), pero el núcleo chipidea llena el usb_phy pasado a través de 'phys' dentro de 'struct ci_hdrc' (ci->usb_phy). Esto provoca la desreferencia del puntero NULL dentro de imx7d_charger_detection(). Solucione el problema buscando también 'phys' en caso de que no se encuentre 'fsl,usbphy'. • https://git.kernel.org/stable/c/746f316b753a83e366bfc5f936cbf0d72d1c2d1d https://git.kernel.org/stable/c/b3265b88e83b16c7be762fa5fb7e0632bce0002c https://git.kernel.org/stable/c/66dd03b10e1c0b2fae006c6e34c18ea8ee033e7b https://git.kernel.org/stable/c/8253a34bfae3278baca52fc1209b7c29270486ca •
CVSS: 4.7EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47412 – block: don't call rq_qos_ops->done_bio if the bio isn't tracked
https://notcve.org/view.php?id=CVE-2021-47412
In the Linux kernel, the following vulnerability has been resolved: block: don't call rq_qos_ops->done_bio if the bio isn't tracked rq_qos framework is only applied on request based driver, so: 1) rq_qos_done_bio() needn't to be called for bio based driver 2) rq_qos_done_bio() needn't to be called for bio which isn't tracked, such as bios ended from error handling code. Especially in bio_endio(): 1) request queue is referred via bio->bi_bdev->bd_disk->queue, which may be gone since request queue refcount may not be held in above two cases 2) q->rq_qos may be freed in blk_cleanup_queue() when calling into __rq_qos_done_bio() Fix the potential kernel panic by not calling rq_qos_ops->done_bio if the bio isn't tracked. This way is safe because both ioc_rqos_done_bio() and blkcg_iolatency_done_bio() are nop if the bio isn't tracked. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: no llame a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. El framework rq_qos solo se aplica en el controlador basado en solicitudes, por lo que: 1) rq_qos_done_bio() no necesita hacerlo ser llamado para un controlador basado en biografía 2) No es necesario llamar a rq_qos_done_bio() para una biografía que no está rastreada, como una biografía terminada por un código de manejo de errores. Especialmente en bio_endio(): 1) la cola de solicitudes se remite a través de bio->bi_bdev->bd_disk->queue, que puede desaparecer ya que el recuento de la cola de solicitudes no se puede mantener en los dos casos anteriores 2) q->rq_qos se puede liberar en blk_cleanup_queue() al llamar a __rq_qos_done_bio() Solucione el posible pánico del kernel al no llamar a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. • https://git.kernel.org/stable/c/004b8f8a691205a93d9e80d98b786b2b97424d6e https://git.kernel.org/stable/c/a647a524a46736786c95cdb553a070322ca096e3 https://access.redhat.com/security/cve/CVE-2021-47412 https://bugzilla.redhat.com/show_bug.cgi?id=2282324 • CWE-388: 7PK - Errors •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47410 – drm/amdkfd: fix svm_migrate_fini warning
https://notcve.org/view.php?id=CVE-2021-47410
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix svm_migrate_fini warning Device manager releases device-specific resources when a driver disconnects from a device, devm_memunmap_pages and devm_release_mem_region calls in svm_migrate_fini are redundant. It causes below warning trace after patch "drm/amdgpu: Split amdgpu_device_fini into early and late", so remove function svm_migrate_fini. BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795 devm_release_action+0x51/0x60 Call Trace: ? memunmap_pages+0x360/0x360 svm_migrate_fini+0x2d/0x60 [amdgpu] kgd2kfd_device_exit+0x23/0xa0 [amdgpu] amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu] amdgpu_device_fini_sw+0x45/0x290 [amdgpu] amdgpu_driver_release_kms+0x12/0x30 [amdgpu] drm_dev_release+0x20/0x40 [drm] release_nodes+0x196/0x1e0 device_release_driver_internal+0x104/0x1d0 driver_detach+0x47/0x90 bus_remove_driver+0x7a/0xd0 pci_unregister_driver+0x3d/0x90 amdgpu_exit+0x11/0x20 [amdgpu] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdkfd: corrige la advertencia de svm_migrate_fini. El administrador de dispositivos libera recursos específicos del dispositivo cuando un controlador se desconecta de un dispositivo, las llamadas a devm_memunmap_pages y devm_release_mem_region en svm_migrate_fini son redundantes. Provoca el siguiente seguimiento de advertencia después del parche "drm/amdgpu: dividir amdgpu_device_fini en temprano y tarde", por lo tanto, elimine la función svm_migrate_fini. ERROR: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 ADVERTENCIA: CPU: 1 PID: 3646 en drivers/base/devres.c:795 devm_release_action+0x51/0x60 Seguimiento de llamadas:? • https://git.kernel.org/stable/c/ac7d732b24f4061f8a732ada49b054ab38c63e15 https://git.kernel.org/stable/c/197ae17722e989942b36e33e044787877f158574 •