netdev - XDP socket DOS bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 20 May 2020 22:16:25 +0700
From:   Minh Bùi Quang <minhquangbui99@...il.com>
To:     Magnus Karlsson <magnus.karlsson@...el.com>, bjorn.topel@...el.com
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: XDP socket DOS bug

Dear sir,
In function xdp_umem_reg (net/xdp/xdp_umem.c), there is an initialization
         //size is u64
         umem->npgs = size / PAGE_SIZE;
When look at the definition of xdp_umem struct, I see
        struct xdp_umem {
                 .....
                 u32 npgs;
                 .....
        }
npgs is u32, however the result of division can be bigger than u32
(there is no limit in size which is u64), so the result can be
truncated when assigned to npgs. For example, size is 0x1 000 0000
8000, result of division is 0x1 0000 0008, and the npgs is truncated
to 0x8.
======
In the process of analyzing the consequence of this bug, I found that
only npgs pages get mapped and the size is used to initialize
queue->size. queue->size is used to validate the address provided in
user-supplied xdp_desc in tx path (xdp_generic_xmit). In
xdp_generic_xmit the address provided passed the size check and reach
xdp_umem_get_data. That address is then used as and index to
umem->pages to get real virtual address. This leads to an out of bound
read in umem->pages and if the attacker spray some addresses, he can
use this bug to get arbitrary read.
However, I cannot see any ways to intercept the xdp packet because
that packet is sent to bpf program by design. Therefore, I cannot get
info leak using this bug but I can craft a poc to get kernel panic on
normal user as long as CONFIG_USER_NS=y.

Regards,
Bui Quang Minh

Download attachment "poc.c" of type "application/octet-stream" (4731 bytes)