CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47417 – libbpf: Fix memory leak in strset
https://notcve.org/view.php?id=CVE-2021-47417
In the Linux kernel, the following vulnerability has been resolved: libbpf: Fix memory leak in strset Free struct strset itself, not just its internal parts. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: libbpf: repara la pérdida de memoria en strset Libera la estructura strset en sí, no solo sus partes internas. • https://git.kernel.org/stable/c/90d76d3ececc74bf43b2a97f178dadfa1e52be54 https://git.kernel.org/stable/c/9e8e7504e09831c469b67d6dc11d9a72654bdb8c https://git.kernel.org/stable/c/b0e875bac0fab3e7a7431c2eee36a8ccc0c712ac •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47416 – phy: mdio: fix memory leak
https://notcve.org/view.php?id=CVE-2021-47416
In the Linux kernel, the following vulnerability has been resolved: phy: mdio: fix memory leak Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phy: mdio: arreglar pérdida de memoria. Syzbot informó una pérdida de memoria en la interfaz del bus MDIO, el problema estaba en una lógica de estado incorrecta. • https://git.kernel.org/stable/c/46abc02175b3c246dd5141d878f565a8725060c9 https://git.kernel.org/stable/c/25e9f88c7e3cc35f5e3d3db199660d28a15df639 https://git.kernel.org/stable/c/2250392d930bd0d989f24d355d6355b0150256e7 https://git.kernel.org/stable/c/f4f502a04ee1e543825af78f47eb7785015cd9f6 https://git.kernel.org/stable/c/2397b9e118721292429fea8807a698e71b94795f https://git.kernel.org/stable/c/414bb4ead1362ef2c8592db723c017258f213988 https://git.kernel.org/stable/c/0d2dd40a7be61b89a7c99dae8ee96389d27b413a https://git.kernel.org/stable/c/064c2616234a7394867c924b5c1303974 •
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 •