linux-kernel - Re: [PATCH net-next v6 7/8] net: check for driver support in netmem TX

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250304161748.42b71228@kernel.org>
Date: Tue, 4 Mar 2025 16:17:48 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, kvm@...r.kernel.org,
 virtualization@...ts.linux.dev, linux-kselftest@...r.kernel.org, Donald
 Hunter <donald.hunter@...il.com>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon
 Horman <horms@...nel.org>, Jonathan Corbet <corbet@....net>, Andrew Lunn
 <andrew+netdev@...n.ch>, Jeroen de Borst <jeroendb@...gle.com>, Harshitha
 Ramamurthy <hramamurthy@...gle.com>, Kuniyuki Iwashima <kuniyu@...zon.com>,
 Willem de Bruijn <willemb@...gle.com>, David Ahern <dsahern@...nel.org>,
 Neal Cardwell <ncardwell@...gle.com>, "Michael S. Tsirkin"
 <mst@...hat.com>, Jason Wang <jasowang@...hat.com>, Xuan Zhuo
 <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez
 <eperezma@...hat.com>, Stefan Hajnoczi <stefanha@...hat.com>, Stefano
 Garzarella <sgarzare@...hat.com>, Shuah Khan <shuah@...nel.org>,
 sdf@...ichev.me, asml.silence@...il.com, dw@...idwei.uk, Jamal Hadi Salim
 <jhs@...atatu.com>, Victor Nogueira <victor@...atatu.com>, Pedro Tammela
 <pctammela@...atatu.com>, Samiullah Khawaja <skhawaja@...gle.com>
Subject: Re: [PATCH net-next v6 7/8] net: check for driver support in netmem
 TX

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.