On Fri, 28 Feb 2025 17:53:24 -0800 Mina Almasry wrote: > On Fri, Feb 28, 2025 at 4:43 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Thu, 27 Feb 2025 04:12:08 +0000 Mina Almasry wrote: > > > + if (!skb_frags_readable(skb) && !dev->netmem_tx) > > > > How do you know it's for _this_ device tho? > > Maybe a noob question, but how do we end up here with an skb that is > not targeted for the 'dev' device? We are checking in > tcp_sendmsg_locked that we're targeting the appropriate device before > creating the skb. Is this about a packet arriving on a dmabuf bound to > a device and then being forwarded through another device that doesn't > own the mapping, bypassing the check? Forwarded or just redirected by nft/bpf/tc > > The driver doesn't seem to check the DMA mapping belongs to it either. > > > > Remind me, how do we prevent the unreadable skbs from getting into the > > Tx path today? > > I'm not sure if this is about forwarding, or if there is some other > way for unreadable skbs to end up in the XT path that you have in > mind. At some point in this thread[1] we had talked about preventing > MP bound devices from being lower devices at all to side step this > entirely but you mentioned that may not be enough, and we ended up > sidestepping only XDP entirely. > > [1] https://lore.kernel.org/bpf/20240821153049.7dc983db@xxxxxxxxxx/ 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 ?
