netdev - Re: [PATCH] af_packet: Fix softirq mismatch in tpacket

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: <daa7deb0-8412-4aa3-ab76-a2244995c3f3@kernel.org>
Date: Fri, 20 Sep 2024 09:01:15 -0600
From: David Ahern <dsahern@...nel.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 Ben Greear <greearb@...delatech.com>, netdev@...r.kernel.org,
 Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH] af_packet: Fix softirq mismatch in tpacket_rcv

On 9/20/24 2:57 AM, Willem de Bruijn wrote:
> Ben Greear wrote:
>> On 9/19/24 13:00, David Ahern wrote:
>>> On 9/19/24 10:44 AM, Willem de Bruijn wrote:
>>>> Yes, it seems that VRF calls dev_queue_xmit_nit without the same BH
>>>> protections that it expects.
>>>>
>>>> I suspect that the fix is in VRF, to disable BH the same way that
>>>> __dev_queue_xmit does, before calling dev_queue_xmit_nit.
>>>>
>>>
>>> commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853 removed the bh around
>>> dev_queue_xmit_nit:
>>>
>>> diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
>>> index 6043e63b42f9..43f374444684 100644
>>> --- a/drivers/net/vrf.c
>>> +++ b/drivers/net/vrf.c
>>> @@ -638,9 +638,7 @@ static void vrf_finish_direct(struct sk_buff *skb)
>>>                  eth_zero_addr(eth->h_dest);
>>>                  eth->h_proto = skb->protocol;
>>>
>>> -               rcu_read_lock_bh();
>>>                  dev_queue_xmit_nit(skb, vrf_dev);
>>> -               rcu_read_unlock_bh();
>>>
>>>                  skb_pull(skb, ETH_HLEN);
>>>          }
>>
>> So I guess we should revert this? 
> 
> Looks like it to me.
> 
> In which case good to not just revert, but explain why, and probably
> copy the comment that is present in __dev_queue_xmit.
> 

Ben: does it resolve the problem you were investigating?

It would be good to add a selftest that sets up a VRF, attaches tcpdump
and then sends a few seconds of iperf3 traffic through it. That should
be similar to the use case here and I expect it to create a similar
crash. That should help prevent a regression in addition to the comment.