CVE-2021-47013

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:emac/emac-mac: Se corrige un uso after free en emac_mac_tx_buf_send En emac_mac_tx_buf_send, llama a emac_tx_fill_tpd(..,skb,..). Si ocurre algún error en emac_tx_fill_tpd(), el skb se liberará mediante dev_kfree_skb(skb) en la rama de error de emac_tx_fill_tpd(). Pero el skb liberado todavía se usa a través de skb->len por netdev_sent_queue(,skb->len). Como observé que emac_tx_fill_tpd() no ha modificado el valor de skb->len, por lo tanto mi parche asigna skb->len a 'len' antes del posible free y usa 'len' en lugar de skb->len más tarde.

A use-after-free flaw was found in the Linux kernel’s Qualcomm Gigabit Ethernet Media Access Controller (EMAC) driver in how a user triggers an error path in the emac_tx_fill_tpd function. This flaw allows a local user to crash or potentially escalate their privileges on the system.

In the Linux kernel, the following vulnerability has been resolved: net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later.

An update for kernel is now available for Red Hat Enterprise Linux 8.8 Extended Update Support. Issues addressed include null pointer and use-after-free vulnerabilities.