Re: CVE-2020-14386: Linux kernel: af_packet.c vulnerability

[Solar Designer <solar () openwall com>]

On Thu, Sep 03, 2020 at 08:16:15PM +0300, Or Cohen wrote:
> I discovered the vulnerability while auditing the 5.7 kernel sources.
>
> The bug occurs in tpacket_rcv function, when calculating the netoff
> variable (unsigned short), po->tp_reserve (unsigned int) is added to
> it which can overflow netoff so it gets a small value.
>
> macoff is calculated using: "macoff = netoff - maclen", we can control
> macoff so it will receive a small value (specifically, smaller then
> sizeof(struct virtio_net_hdr)).
>
> Later, when running the following code:
> ...
> if (do_vnet &&
>    virtio_net_hdr_from_skb(skb, h.raw + macoff -
> sizeof(struct virtio_net_hdr),
> ...
>
> If do_vnet is set, and because macoff < sizeof(struct virtio_net_hdr)
> a pointer to a memory area before the h.raw buffer will be sent to
> virtio_net_hdr_from_skb. This can lead to an out-of-bounds write of
> 1-10 bytes, controlled by the user.
>
> The h.raw buffer is allocated in alloc_pg_vec and it's size is
> controlled by the user.
>
> The stack trace is as follows at the time of the crash: ( linux v5.7 )
>
> #0  memset_erms () at arch/x86/lib/memset_64.S:66
> #1  0xffffffff831934a6 in virtio_net_hdr_from_skb

In the proposed patch you have:

Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")

That commit was in July 2008.

While this is technically correct, it can be misleading, so I am posting
the below clarification/excerpt from the discussion on linux-distros:

> On Wed, Sep 2, 2020 at 4:47 PM Eric Dumazet <edumazet () google com> wrote:
> > At the time of commit 8913336a7e8d  virtio_net was not there yet.

On Wed, Sep 02, 2020 at 05:14:03PM +0300, Or Cohen wrote:
> This is the commit that introduced the feature and the arithmetic
> overflow exists there, which is the root cause of the bug.
> However, you are correct that it is probably not possible to trigger
> the memory corruption because virtio_net is not there.

I just looked into it some further, and it appears the bug was exposed
to the known way to trigger it with 58d19b19cd99 ("packet: vnet_hdr
support for tpacket_rcv") in February 2016, which first got into 4.6-rc1.

Alexander