Date: Fri, 4 Sep 2020 09:36:03 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Cc: Or Cohen <orcohen@...oaltonetworks.com>, Nadav Markus <nmarkus@...oaltonetworks.com>, Eric Dumazet <edumazet@...gle.com> Subject: Re: CVE-2020-14386: Linux kernel: af_packet.c vulnerability 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@...gle.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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.