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
Attachment:
poc.c
Description: Binary data
