On Mon, 3 Mar 2025 19:53:44 -0800 Mina Almasry wrote: > > Upper devices and BPF access is covered I think, by the skbuff checks. > > But I think we missed adding a check in validate_xmit_skb() to protect > > the xmit paths of HW|virt drivers. You can try to add a TC rule which > > forwards all traffic from your devmem flow back out to the device and > > see if it crashes on net-next ? > > No crash, but by adding debug logs I'm detecting that we're passing > unreadable netmem dma-addresses to the dma_unmap_*() APIs, which is > known to be unsafe. I just can't reproduce an issue because my > platform has the IOMMU disabled. > > I guess I do need to send the hunk from validate_xmit_skb() as a fix > to net and CC stable. > > Another thing I'm worried about is ip_forward() inserting an > unreadable skb into the tx path somewhere higher up the stack which > calls more code that isn't expecting unreadable skbs? Specifically > worried about skb_frag_ref/unref. Does this sound like a concern as > well? Or is it a similar code path to tc? I'd say similar to tc. We can protect drivers with a check in validate_xmit_skb(). The second API surface we need to filter on is skb / skb_frag helpers. The third is socket API / opt-in for in-kernel socket readers. Driver and socket should be "easy" to cover with an explicit opt in. You already covered skb APIs but it's less centralized and there may be some abuses we are not aware of. Which is why patch 1 worries me a little.
