CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47037 – ASoC: q6afe-clocks: fix reprobing of the driver
https://notcve.org/view.php?id=CVE-2021-47037
In the Linux kernel, the following vulnerability has been resolved: ASoC: q6afe-clocks: fix reprobing of the driver Q6afe-clocks driver can get reprobed. For example if the APR services are restarted after the firmware crash. However currently Q6afe-clocks driver will oops because hw.init will get cleared during first _probe call. Rewrite the driver to fill the clock data at runtime rather than using big static array of clocks. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: q6afe-clocks: corrección de reprobación del controlador El controlador Q6afe-clocks puede ser reprobado. • https://git.kernel.org/stable/c/520a1c396d1966b64884d8e0176a580150d5a09e https://git.kernel.org/stable/c/6893df3753beafa5f7351228a9dd8157a57d7492 https://git.kernel.org/stable/c/62413972f5266568848a36fd15160397b211fa74 https://git.kernel.org/stable/c/96fadf7e8ff49fdb74754801228942b67c3eeebd •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47036 – udp: skip L4 aggregation for UDP tunnel packets
https://notcve.org/view.php?id=CVE-2021-47036
In the Linux kernel, the following vulnerability has been resolved: udp: skip L4 aggregation for UDP tunnel packets If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there are UDP tunnels available in the system, udp_gro_receive() could end-up doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header. That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc. Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the current packet could land in a UDP tunnel, and let udp_gro_receive() do GRO via udp_sk(sk)->gro_receive. The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets. Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity. v1 -> v2: - hopefully clarify the commit message En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: omitir la agregación L4 para paquetes de túnel UDP Si NETIF_F_GRO_FRAGLIST o NETIF_F_GRO_UDP_FWD están habilitados y hay túneles UDP disponibles en el sistema, udp_gro_receive() podría terminar realizando la agregación L4 (ya sea SKB_GSO_UDP_L4 o SKB_GSO_FRAGLIST) en el nivel del túnel UDP externo para paquetes que transportan efectivamente un encabezado de túnel UDP. Eso podría causar corrupción del protocolo interno. • https://git.kernel.org/stable/c/9fd1ff5d2ac7181844735806b0a703c942365291 https://git.kernel.org/stable/c/450687386cd16d081b58cd7a342acff370a96078 https://git.kernel.org/stable/c/18f25dc399901426dff61e676ba603ff52c666f7 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47035 – iommu/vt-d: Remove WO permissions on second-level paging entries
https://notcve.org/view.php?id=CVE-2021-47035
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove WO permissions on second-level paging entries When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration. • https://git.kernel.org/stable/c/b802d070a52a1565b47daaa808872cfbd4a17b01 https://git.kernel.org/stable/c/c848416cc05afc1589edba04fe00b85c2f797ee3 https://git.kernel.org/stable/c/89bd620798704a8805fc9db0d71d7f812cf5b3d2 https://git.kernel.org/stable/c/25faff78138933244c678c7fc78f7c0340fa04a0 https://git.kernel.org/stable/c/66c24699f266ff310381a9552d3576eea8ad6e20 https://git.kernel.org/stable/c/eea53c5816889ee8b64544fa2e9311a81184ff9c •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47034 – powerpc/64s: Fix pte update for kernel memory on radix
https://notcve.org/view.php?id=CVE-2021-47034
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix pte update for kernel memory on radix When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. • https://git.kernel.org/stable/c/f1cb8f9beba8699dd1b4518418191499e53f7b17 https://git.kernel.org/stable/c/b3d5d0983388d6c4fb35f7d722556d5595f167a7 https://git.kernel.org/stable/c/73f9dccb29e4f82574bec2765c0090cdb0404301 https://git.kernel.org/stable/c/84c0762633f2a7ac8399e6b97d3b9bb8e6e1d50f https://git.kernel.org/stable/c/01ac203e2119d8922126886ddea309fb676f955f https://git.kernel.org/stable/c/e40c52ee67b155ad59f59e73ea136d02685f0e0d https://git.kernel.org/stable/c/b8b2f37cf632434456182e9002d63cbc4cccc50c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47033 – mt76: mt7615: fix tx skb dma unmap
https://notcve.org/view.php?id=CVE-2021-47033
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: fix tx skb dma unmap The first pointer in the txp needs to be unmapped as well, otherwise it will leak DMA mapping entries En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7615: fix tx skb dma unmap. El primer puntero en el txp también debe desasignarse; de lo contrario, se filtrarán entradas de mapeo DMA • https://git.kernel.org/stable/c/27d5c528a7ca08dcd44877fdd9fc08b76630bf77 https://git.kernel.org/stable/c/75bc5f779a7664d1fc19cb915039439c6e58bb94 https://git.kernel.org/stable/c/a025277a80add18c33d01042525a74fe5b875f25 https://git.kernel.org/stable/c/821ae236ccea989a1fcc6abfc4d5b74ad4ba39d2 https://git.kernel.org/stable/c/ebee7885bb12a8fe2c2f9bac87dbd87a05b645f9 •