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